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SECTION  1 


INTRODUCTION 


This  document  is  a  final  report  on  research  into  availability  models  for  distributed,  MLS  C2  systems. 
The  research  has  been  performed  under  the  Assured  Service  Concepts  and  Models  (ASCM)  project. 
The  goals  of  the  ASCM  project  are  to: 

a.  Develop  security  policies  and  models  for  distributed  C2  systems. 

b.  Develop  availability  policies  and  models  for  distributed  C2  systems. 

c.  Analyze  trade-offs  between  security  and  availability. 

d.  Analyze  a  real-system  with  respect  to  the  policies  and  models  developed  on  the  project. 

This  report  addresses  tasks  b  and  c. 


1.1  PURPOSE 

In  [9],  computer  security  is  defined  to  consist  of: 

a.  secrecy  —  protection  from  unathorized  disclosure  of  data 

b.  integrity  —  protection  from  unauthorized  modification  of  data 

c.  availability  —  protection  from  unauthorized  denial  of  Service 

A  system’s  secrecy,  integrity,  and  availability  control  objectives  state  the  secrecy,  integrity,  and 
availability  requirements  placed  on  the  system. 

Historical  and  technical  reasons  why  denial  of  service  has  often  been  ignored  in  computer  security 
projects  are  discussed  in  [9].  The  main  technical  reason  is  that  much  greater  progress  has  been 
made  on  formalizing  secrecy  and  integrity  than  denial  of  service.  Since  it  is  difficult  to  analyze  a 
system  with  respect  to  properties  that  are  not  clearly  defined,  it  has  been  more  feasible  to  analyze 
systems  with  respect  to  secrecy  and  integrity  than  with  respect  to  denial  of  service.  The  author  of 
[9]  goes  as  far  as  stating: 

To  sum  up,  security  relates  to  secrecy  first,  integrity  second,  and  denial  of  service  a 
distant  third.  To  help  you  remember  this,  memorize  the  computer  security  researcher’s 
favorite  (tongue-in-cheek)  phrase:  “I  don’t  care  if  it  works,  as  long  as  it  is  secure.” 

The  suggestion  for  addressing  denial  of  service  is  to  use  structured  development,  fault  tolerance, 
and  software  reliability  techniques.  These  techniques  are  of  little  use  for  addressing  denial  of  service 
unless  we  understand  what  denial  of  service  means.  So,  by  formalizing  denial  of  service,  we  will 
be  able  to  perform  analysis  to  determine  whether  an  application  of  these  techniques  to  a  system 
adequately  addresses  denial  of  service. 
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As  techniques  for  denial  of  service  often  conflict  with  the  secrecy  control  objective  (see  [5]),  it  is 
also  important  to  develop  techniques  for  analyzing  trade-offs  between  MLS  security  (secrecy)  and 
availability. 

1.2  ORGANIZATION 

In  Section  2  we  discuss  formalisms  that  can  be  used  for  stating  security  and  availability  properties. 
In  addition  to  describing  different  formalisms,  this  section  will  discuss  relationships  between  the 
formalisms  and  advantages  and  disadvantages  of  the  formalisms.  In  Section  3  we  discuss  denial  of 
service  threats  and  conditions.  After  informally  describing  each  threat  and  condition,  we  develop 
a  formal  definition.  In  this  section  we  address  fault  tolerance  as  a  class  of  preventing  denial  of 
service.  In  Section  4  we  discuss  techniques  for  making  trade-offs  between  denial  of  service  and 
MLS  security.  Finally,  in  Section  5  we  summarize  our  findings. 


SECTION  2 


FORMALISMS 

Although  it  is  possible  to  formalize  concepts  to  some  degree  in  English,  inherent  ambiguities  in 
English  usually  prevent  complete  formalization.  Furthermore,  English  is  often  less  concise  than 
more  formal  languages.  Thus,  before  attempting  to  formalize  concepts,  it  is  useful  to  develop  a 
formalism  appropriate  for  the  given  concept.  As  we  shall  see,  there  does  not  appear  to  be  one 
formalism  that  is  appropriate  for  all  problem  domains. 

As  substantial  work  has  already  been  devoted  to  developing  formalisms  for  reasoning  about  com¬ 
puter  systems,  rather  than  developing  new  formalisms  we  describe  existing  formalisms  that  appear 
useful  for  reasoning  about  computer  systems.  Since  we  are  using  existing  formalisms  rather  than 
developing  new  formalisms,  we  give  only  a  brief  description  of  each  formalism.  More  in  depth 
descriptions  can  be  found  in  the  cited  references.  After  describing  the  formalisms,  we  discuss  the 
problem  domains  for  which  each  is  appropriate  and  consider  relationships  that  exist  between  the 
various  formalisms. 

We  consider  the  following  formalisms  in  this  section: 

•  State  Machines 

•  Traces 

•  Petri  Nets 

•  Temporal  Logic 

•  Interval  Temporal  Logic 

•  Real  Time  Logic 


2.1  STATE  MACHINES 

In  this  section,  we  describe  one  type  of  state  machine  model,  the  Mealy  machine.  For  a  more 
detailed  description  of  M  aly  machines  as  well  as  descriptions  of  other  types  of  state  machine 
models  see  [21]. 

A  Mealy  machine  is  characterized  by  the  following  attributes: 

•  a  set  of  states,  S 

•  an  initial  state,  initial 

•  a  set  of  operations,  OV 

•  a  set  of  outputs,  OUT 
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•  a  rule  indicating  whether  a  given  operation  can  be  executed  in  a  given  state  (we  will  use 
valid(op,  st )  to  represent  that  op  can  be  executed  in  st ) 

•  whenever  op  can  be  executed  in  st,  a  rule  indicating: 

-  the  state  resulting  from  executing  the  operation  (which  we  will  denote  by  stop) 

-  the  output  that  results  from  the  operation  (which  we  will  denote  by  output  (op,  st)) 

The  set  OUT  represents  the  set  of  externally  visible  events.  Each  externally  visible  event  is  gener¬ 
ated  by  some  operation  in  the  set  OP.  The  elements  of  the  set  S  provide  an  encoding  of  information 
about  the  history  of  the  system  that  is  needed  to  determine  the  manner  in  which  the  system  should 
act  when  an  operation  is  executed.  For  example: 

Suppose  that  we  consider  an  airplane.  We  might  define  our  set  of  states  to  be: 

-  PARKED  —  the  plane  is  on  the  ground  and  not  moving;  this  is  the  initial  state, 

-  MOVING  —  the  plane  is  on  the  ground  and  moving, 

-  TAKING-OFF —  the  plane  is  in  the  process  of  taking-off, 

-  LANDING  —  the  plane  is  in  the  process  of  landing, 

-  FLYING —  the  plane  has  taken  off  and  has  not  yet  started  landing, 

and  our  set  of  operations  to  be: 

-  Start-Engine  —  causes  a  transition  from  PARKED  to  MOVING, 

-  Take-Off —  causes  a  transition  from  MOVING  to  TAKING-OFF 

-  Land  —  causes  a  transition  from  FLYING  to  LANDING 

-  St  op- Engine  —  causes  a  transition  from  MOVING  to  PARKED , 

-  In- Air  —  causes  a  transition  from  MO  VING  to  FLYING, 

-  On-Ground  —  causes  a  transition  from  FLYING  to  MOVING 

In  this  example,  the  states  represent  the  present  status  of  the  airplane;  the  operations  indicate  the 
ways  in  which  the  status  of  the  airplane  can  be  changed;  and  the  restrictions  of  the  manner  in 
which  the  airplane  can  change  states  in  the  real-world  are  captured  in  the  constraints  on  which 
operations  can  be  applied  in  each  state. 

2.1.1  Advantages 

There  are  three  advantages  to  using  state  machine  models:  they  often  have  a  clearer  correspondence 
with  the  systems  that  they  model,  they  allow  for  some  automated  anaylsis,  and  they  specify  the 
operations  in  such  a  manner  that  there  is  little  “coupling”  between  operations. 
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Since  there  is  no  objective  measure  for  the  clarity  of  the  correspondence  betw  jen  a  system  and  a 
model,  our  claim  that  state  machines  provide  a  clearer  correspondence  is  subjective.  Some  factors 
that  contribute  to  this  clarity  in  state  machine  models  are: 

a.  There  is  often  a  close  similarity  between  the  “data  structures”  used  in  a  state  machine  model 
and  those  used  in  the  actual  system.  For  example,  it  seems  reasonable  that  a  flight  control 
system  would  maintain  the  following  data: 

•  whether  the  engine  is  on, 

•  whether  a  take-off  is  in  process, 

•  whether  a  landing  is  in  process, 

•  whether  the  plane  is  airborn 

each  of  these  data  components  can  be  represented  by  a  Boolean  variable  resulting  in  a  state 
comprised  of  four  Boolean  variables.  Then,  the  state  of  the  actual  system  can  be  represented 
as  follows: 

<  vltv2,v3,v4> 

where  Vi-V4  are  Boolean  values  indicating  the  value  of  each  of  the  four  Boolean  variables 
identified  above.  Then,  the  mapping  between  the  state  machine  model  and  the  actual  system 
is: 

•  PARKED  ~<  F,  F,  F,  F  >, 

.  MOVING  <-+<  T,F,F,F  >, 

•  TA  KING-  OFF  «-»  <  T,  T,  F,  F  > , 

•  FLYING  *-*<  T,F,  F,T  >, 

•  LA NDING ~<  T,F,T,T> 

The  close  correspondence  between  states  in  the  model  and  states  in  the  actual  system  facili¬ 
tates  developing  an  accurate  model  of  the  system  and  drawing  conclusions  about  the  actual 
system  from  analysis  of  the  model. 

Note  that  it  is  not  generally  true  that  all  of  the  states  in  the  actual  system  correspond  to 
states  in  the  model.  For  example,  <  F,  F,  F,T  >  does  not  correspond  to  any  of  the  states  in 
our  example  model.  This  is  the  state  in  which  the  flight  control  system  believes  that  the  plane 
is  airborn  even  though  the  engine  is  off.  This  is  not  valid  in  the  simple  model  presented  here 
(although  it  could  be  addressed  by  adding  a  state,  such  as  STALLED ,  to  the  model).  In  order 
to  establish  the  consistency  between  our  example  model  and  actual  system,  it  is  necessary  to 
address  the  possibility  of  invalid  states  being  reached  in  the  actual  system. 
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b.  State  machines  provide  a  procedural  view  of  the  world. 

As  implementation  languages  are  often  procedural,  a  modeling  approach  that  emphasizes  the 
procedural  aspects  of  computing  is  often  appropriate. 

We  do  not  mean  to  suggest  that  state  machine  models  are  always  more  understandable  than  models 
in  other  formalisms.  Care  must  be  taken  when  developing  the  model  to  choose  states  and  operations 
that  are  easily  mapped  to  the  states  and  operations  of  the  actual  system. 

If  the  number  of  states  and  operations  in  a  state  machine  model  is  small,  then  it  is  often  possible 
to  automate  the  analysis.  For  example,  it  is  often  desirable  to  determine  whether  certain  states  are 
reachable  from  other  states.  This  question  can  be  answered  by  performing  a  brute  force  analysis  to 
determine  all  the  states  states  reachable  from  a  given  initial  state.  Clearly  this  analysis  becomes 
infeasible  if  there  are  too  many  states  or  operations.  This  does  not  mean  that  it  is  not  possible 
to  analyze  systems  with  a  large  number  of  states,  it  just  means  that  a  more  intelligent  analysis 
procedure  must  be  used. 

A  common  approach  that  is  taken  with  safety  problems  is  to  model  the  system  as  a  state  machine, 
determine  the  set  of  states  that  are  “safe”,  and  show  that  it  is  not  possible  to  effect  a  transition 
from  a  “safe”  state  to  an  “unsafe”  state  as  the  result  of  executing  an  operation.  This  provides  an 
inductive  argument  that  all  the  reachable  states  are  “safe”  whenever  the  initial  state  is  safe. 

By  saying  that  the  specifications  of  the  operations  are  loosely  “coupled”,  we  mean  that  it  is  possible 
to  understand  how  any  given  operation  behaves  without  unc  u sanding  how  the  other  operations 
behave.  This  makes  the  specifications  easier  to  understand  because  it  is  often  possible  to  understand 
how  a  given  operation  behaves  without  understanding  how  the  whole  system  works.  Maintenance 
of  the  specifications  is  also  simplified  as  there  is  less  danger  that  a  change  in  the  specification  of  an 
operation  will  ripple  through  the  specifications  of  many  other  operations. 


2.1.2  Disadvantages 

There  are  three  drawbacks  to  using  the  state  machine  paradigm:  there  are  times  in  which  it  is 
desirable  to  make  distinctions  between  different  types  of  operations,  it  is  difficult  to  represent 
concurrency  with  state  machines,  and  state  machines  often  have  more  implementation  detail  than 
is  necessary. 

In  the  state  machine  model  for  the  airplane,  the  operations  can  be  divided  into  two  classes.  The 
first  class,  { Start-Engine ,  Stop-Engine,  Land ,  Take-Off},  consists  of  operations  that  more  naturally 
fit  the  intuitive  notion  of  “executing”.  For  example,  it  is  natural  to  have  an  operation  corresponding 
to  the  pilot  starting  the  engine.  The  second  class,  {In-Air,  On-Ground} ,  consists  of  operations  that 
seem  artificial.  For  example,  there  is  not  really  an  In- A  ir  operation  that  can  be  executed  to  cause 
the  plane  to  become  airborn.  As  a  result  of  the  physical  laws  governing  the  behavior  of  the  plane, 
it  becomes  airborn  at  some  time  after  the  initiation  of  the  take-off.  As  we  will  see  later,  other 
formalisms  allow  us  to  consider  becoming  airborn  and  touching  down  simply  as  events  that  occur 
rather  than  as  operations. 


9 


Since  each  operation  in  a  state  machine  model  is  atomic,  it  is  difficult  to  represent  concurrency  in 
a  realistic  manner  using  state  machines.  For  example: 

Suppose  we  consider  a  database  system.  For  simplicity,  we  will  consider  the  case  in  which 
there  is  only  one  data  item  in  the  system.  We  might  model  the  system  as  having  one  state 
corresponding  to  each  possible  value  for  the  data  item  and  operations  Update v  to  change  the 
value  associated  with  the  data  item  to  v  and  Retrieve  to  retrieve  the  value  associated  with 
the  data  item. 

Suppose  that  our  values  are  pairs  of  integers  (t>i,U2)  and  that  we  want  to  enforce  iq  >  t>2  as 
a  consistency  constraint.  To  analyze  whether  the  system  enforces  this  constraint,  we  might 
take  the  following  steps: 

a.  Check  that  tq  >  t/2  in  the  initial  state. 

b.  Check  that  the  Update  operation  only  changes  the  state  when  tq  >  w2  and  then  it  does  so 
by  transitioning  to  the  state  indicated  by  (iq,v2). 

Although  this  is  a  nice,  simple  model  of  the  system  and  it  is  easy  to  determine  whether  the 
consistency  constraint  is  enforced,  the  model  and  analysis  are  worthless  if  the  system  allows 
for  concurrent  update  operations  to  be  executed.  For  example,  if  Update (2,i)  and  Update^300i 4) 
are  executed  concurrently,  the  following  might  occur  in  the  system: 

a.  Since  300  is  greater  than  4,  the  system  allows  Update^ooA)  to  change  the  state. 

b.  As  a  first  step  in  changing  the  state,  the  system  changes  the  first  component  of  the  state 
to  300. 

c.  Since  2  is  greater  than  1,  the  system  allows  Update^ti)  to  change  the  state. 

d.  The  system  changes  the  first  component  of  the  state  to  2  and  the  second  component  to  1. 

e.  The  system  completes  the  Update^ 0,4)  operation  by  setting  the  second  component  of  the 
state  to  4. 

So,  the  final  state  reached  in  the  system  will  be  (2, 4)  which  violates  the  consistency  constraint. 

In  order  to  address  this  issue,  the  model  must  be  detailed  enough  to  represent  the  concurrency  in 
the  system.  For  example,  we  might  change  our  model  as  follows: 

Let  B\  and  52  be  bags1  of  integers  and  Vi  and  v2  be  integers.  Then,  we  can  define  our  states 
to  be  tuples  <  Bi,  B2,  tq,  v2  >.  Intuitively,  Bi  and  i?2  would  represent  values  that  have  been 
requested  for  tq  and  u2,  respectively. 

In  addition  to  the  Updatev  operations,  we  would  have  operations  Updated  and  Update2{  for 
each  integer  i.  The  state  transition  function  would  be  defined  so  that  Updatev  adds  tq  and  v2 
to  B\  and  J52,  respectively,  if  (tq,u2)  is  a  valid  request.  The  operation  Updated  can  only  be 
executed  when  i  is  an  element  of  Bi  in  the  current  state.  In  that  case,  a  transition  is  made 
to  a  state  in  which: 

'A  bag  is  a  generalization  of  a  set  in  which  the  number  of  occurrences  of  each  element  is  significant  in  addition  to 
which  elements  are  present. 
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-  B\  has  one  occurrence  of  i  removed. 

-  vi  has  value  t. 

-  i?2  and  v-i  are  unchanged. 

Update2i  is  defined  in  a  similar  fashion. 

Then,  the  model  is  sufficiently  detailed  for  the  violation  of  the  consistency  constraint  to  be 
visible.  For  example: 

Suppose  the  initial  state  is  <  {},{}, «i,  >  and  we  consider  the  operation  sequence 

Update^ 3oo, 4)>  Update^ 2,i),  Update  13Qq,  Update i2,  Update2i,  Update24.  Then,  the  following 
states  would  be  reached: 

a.  <  {300},{4},ai,a2  >, 

b.  <  {2,300},{l,4},ai,<z2  >, 

c.  <  {2}, {1,4}, 300, o2  >, 

d.  <  {}, {l,4},2,a2  >, 

e.  <{},{4},2,1>, 

f.  <  {},{}, 2, 4  >. 

Clearly,  the  final  state  violates  the  consistency  constraint.  Depending  on  the  values  of 
aj  and  a2,  it  is  possible  that  some  of  the  intermediate  states  also  violate  the  consistency 
constraint. 

Once  the  flaw  in  the  system  has  been  detected  and  some  means  of  correcting  it  has  been 
determined,  the  model  can  be  updated  to  reflect  the  new  design  of  the  system  and  the  analysis 
can  be  repeated  to  determine  whether  the  new  system  design  is  appropriate. 

The  above  example  demonstrates  that  rather  than  being  impossible  to  address  concurrency  in 
a  state  machine  model,  it  is  only  more  difficult.  While  it  is  generally  true  that  concurrency  is 
more  difficult  to  analyze,  the  state  machine  paradigm  seems  ill-equipped  to  address  the  issue. 
For  example,  the  operations  Updateli  and  Update2i  are  artificial  in  the  sense  that  they  are  not 
operations  that  a  user  explicitly  executes  but  rather  portions  of  the  processing  required  to  respond 
to  an  explicit  user  request. 

Since  it  is  typically  necessary  to  consider  nondeterminism  to  adequately  address  concurrency,  a 
further  complication  of  the  use  of  our  state  machine  model  to  address  concurrency  is  that  it  does 
not  allow  nondeterministic  operators.  Although  [21]  describes  how  nondeterministic  operators 
can  be  described  in  the  framework  of  deterministic  state  machines,  the  deterministic  state  machine 
models  obtained  generally  have  too  many  states  for  analysis  to  be  feasible.  Once  again,  the  analysis 
is  theoretically  possible,  yet  very  difficult  in  the  state  machine  paradigm. 
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In  the  previous  section  we  claimed  that  one  of  the  advantages  of  the  state  machine  paradigm  was 
that  there  often  was  a  close  correspondence  between  the  “data  structures”  in  a  state  machine 
model  of  a  system  and  the  data  structures  in  the  actual  system.  To  many,  this  represents  a  serious 
disadvantange  of  the  state  machine  paradigm  because  the  model  might  have  more  implementation 
detail  than  it  would  in  other  paradigms.  As  we  will  see  in  the  following  sections,  there  is  a  strong 
connection  between  all  of  the  formalisms.  Thus,  although  it  might  be  common  for  users  of  the 
state  machine  paradigm  to  include  more  implementation  detail  than  is  necessary,  it  is  quite  often 
the  case  that  a  more  carefully  built  model  would  be  just  as  abstract  as  models  in  other  formalisms. 
In  other  words,  there  is  actually  nothing  inherent  in  the  paradigm  that  requires  implementation 
detail  in  the  model. 


2.2  TRACES 

While  the  state  machine  paradigm  concentrates  on  the  current  state  of  the  system,  the  trace 
paradigm  concentrates  on  the  allowable  execution  histories  of  the  system.  In  other  words,  while 
the  state  machine  paradigm  relies  on  the  system  states  to  capture  the  aspects  of  the  execution 
history  of  the  system  that  are  relevant  to  describe  future  behavior  of  the  system,  the  trace  paradigm 
allows  explicit  reference  to  be  made  to  the  execution  history.  The  particular  instance  of  the  trace 
paradigm  that  we  will  discuss  in  this  section  is  CSP  as  described  in  [13]. 

CSP  provides  two  mechanisms  for  the  describing  the  behavior  of  a  system:  the  process  language 
and  sat  predicates.  Underlying  both  of  these  mechanisms  are  events. 

Events  in  the  CSP  model  of  a  system  are  used  to  mark  points  in  time  at  which  system  relevant 
activities  occur.  Referring  to  our  airplane  example,  we  might  have  events: 

•  start  —  request  to  start  engine, 

•  stop  —  request  to  stop  engine, 

•  to  —  request  to  initiate  take-off, 

•  l  —  request  to  initiate  landing, 

•  ab  —  detection  that  plane  has  become  airborn, 

•  td  —  detection  that  plane  has  touched  down 

The  set  of  all  of  the  events  used  in  modeling  the  system  is  called  the  alphabet  of  the  system. 

Many  aspects  of  the  behavior  of  the  system  can  be  described  by  specifying  which  sequences  of 
events  from  the  alphabet  correspond  to  allowable  behaviors  of  the  system.  For  example,  assuming 
that  the  plane  starts  in  a  state  in  which  the  engine  is  off,  the  plane  may  not  become  airborn  until 
the  engine  is  started.  This  means  that  start  must  occur  before  ab.  Thus,  the  sequence  {ab)  is  not 
a  valid  execution  history  of  the  system.  The  set  of  valid  execution  histories  of  the  system  is  called 
the  traces  of  the  system. 
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In  [13],  two  classes  of  systems  are  described.  The  first  class  consists  of  all  systems  that  can  be 
described  solely  in  terms  of  its  traces.  These  are  referred  to  as  the  deterministic  processes.  All 
other  systems  are  termed  nondeterministic  processes.  [13]  characterizes  the  nondeterminism  in 
terms  of  two  constructs,  the  failures  and  divergences  of  the  system.  Intuitively,  the  failures  describe 
actions  in  which  the  system  is  ready  to  participate  but  chooses  to  ignore  while  the  divergences 
describe  instances  in  which  the  system  reaches  a  state  from  which  it  is  impossible  to  reason  about 
its  behavior.  It  is  beyond  the  scope  of  this  report  to  completely  address  the  failures  and  divergences. 
In  this  section,  we  will  only  consider  deterministic  processes.  For  an  in-depth  discussion  of  the 
nondeterministic  processes,  see  [13]. 

In  order  to  specify  a  system  using  a  sat  predicate,  a  Boolean  expression  is  constructed  that  captures 
the  relevant  constraints  on  the  behavior  of  the  system.  Then,  it  is  asserted  that  the  system  satisfies 
the  Boolean  expression.  A  system’s  sat  predicate  is  simply  the  Boolean  expression  that  the  system 
is  asserted  to  satisfy.  For  example,  we  might  use  the  following  as  the  sat  predicate  for  the  airplane 
example: 


tri+ 1 
and  tri+i 
and  tri+i 
and  <7',+i 
and  £r,+i 
and 


start  =>■  (t  =  1  or  tr,-  =  stop) 
stop  =>■  ( tr,  —  start  or  tr,-  =  id) 
to  =>  ( tT{  =  start  or  tr,-  =  td) 
l  =>  tr,  =  ab 
ab  =>  tr,  =  to 
td  =>  tri  =  td 


where  tr  represents  an  arbitrary  trace  of  the  system  and  tr,-  denotes  the  ith  event  in  tr. 

In  this  case,  we  have  derived  the  sat  predicate  by  simply  defining  for  each  event  the  set  of  events 
that  can  precede  it.  Since  the  sat  predicate  can  be  any  Boolean  expression  defined  on  traces,  this 
provides  a  very  powerful  means  for  specifying  behavior. 

The  drawback  of  using  sat  predicates  to  define  behavior  is  that  it  is  difficult  to  determine  their 
consistency  and  completeness.  When  a  sat  predicate  is  used  to  specify  system  behavior,  it  provides 
an  implicit  definition  of  the  set  of  traces.  Our  above  specification  of  the  behavior  of  the  airplane 
should  be  read  as  asserting  that  the  set  of  traces  is  comprised  of  exactly  those  sequences  that  satisfy 
the  sat  predicate.  If  the  sat  predicate  is  too  weak,  then  our  specification  will  be  incomplete  and 
we  will  be  allowing  some  behaviors  that  we  do  not  mean  to  allow.  For  example,  if  we  remove  the 
second  conjunct  (the  requirement  that  tr,-+1  =  stop  (tr,-  =  start  or  tr,  =  td)),  then  we  have 
no  constraint  on  when  the  stop  event  can  occur.  Tlius,  we  would  be  allowing  system  behaviors  in 
which  the  engine  stopped  in  mid-air.  On  the  other  hand,  if  the  sat  predicate  is  too  strong,  then  our 
specification  will  be  inconsistent  and  will  disallow  certain  behaviors  that  we  would  like  to  allow. 
For  example,  if  the  second  conjuct  were  strengthened  to  require  that  the  stop  event  only  occur 
directly  after  the  start  event,  then  we  would  not  allow  the  engine  to  be  stopped  after  the  plane 
touches  down.  As  an  even  more  extreme  example,  if  the  sat  predicate  is  logically  inconsistent  it 
will  not  be  satisfied  by  any  event  sequences  and  the  set  of  traces  will  be  empty. 
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To  facilitate  the  specification  of  the  set  of  traces  for  a  system,  CSP  provides  the  process  language. 
The  process  language  provides  an  algebra  for  building  processes.  For  example,  given  a  process  P 
and  an  event  e,  CSP  uses: 

»  e  — »  P  to  denote  the  process  that  first  does  e  and  then  behaves  like  the  process  P,  and 

•  (ei  — ►  Pi)|(e2  — *•  P2)  to  denote  the  process  that  either  does  ej  and  then  behaves  like  Pi  or 
does  ei  and  then  behaves  like  P2. 

Using  these  operators  from  the  process  language,  we  can  specify  the  airplane  as  the  process  P 
where: 

•  P  =start  — ►  M 

All  a  parked  plane  can  do  is  starts  its  engine  and  behave  like  a  moving  plane. 

•  M  =(to  — >  F)  |(sfop  —*  P) 

A  moving  plane  either  takes-off  and  behaves  like  a  flying  plane  or  stops  its  engine  and  behaves 
like  a  parked  plane. 

•  F  -ab  — *•  /  — ►  td  — *•  M 

A  flying  plane  becomes  airborn,  starts  landing,  touches  down,  and  then  acts  like  a  moving 
plane. 

Given  an  operator  OP  in  the  process  language  and  processes  Pi,...,Pn  for  which  the  sets  of 
traces  are  already  known,  [13]  provides  rules  for  determining  the  set  of  traces  for  the  process  built 
from  Pj , . . . ,  Pn  using  OP.  These  rules  allow  us  to  obtain  the  traces  for  a  complicated  system 
by  determining  the  traces  for  a  set  of  simple  systems  and  combining  the  simple  systems  in  an 
appropriate  fashion. 

The  approach  used  in  [13]  is  to  use  the  process  language  to  specify  the  behavior  of  the  system  and 
to  use  sat  predicates  to  state  properties  of  the  system  that  are  of  interest.  With  this  approach, 
the  processes  P,  M ,  and  F  above  would  be  the  definition  of  the  system  while  the  sat  predicate 
that  we  earlier  used  as  the  definition  of  the  system  would  simply  be  a  consequence  of  the  process 
language  specification  of  the  system.  The  only  time  that  a  sat  predicate  should  be  used  to  define 
the  behavior  of  the  system  rather  than  calling  out  a  consequence  of  the  behavior  specified  by  the 
process  language  is  when  a  choice  has  been  made  to  not  specify  the  system  in  the  process  language. 

The  following  constructs  described  in  [13]  will  be  used  in  this  report: 

•  P\\Q  —  parallel  composition  of  processes  P  and  Q  with  interaction  between  P  and  Q, 

•  !e  — *  P  —  the  process  that  outputs  event  e  and  then  behaves  like  process  P, 

•  ?x  — *  P  —  the  process  that  inputs  a  value  for  x  and  then  behaves  like  process  P, 

•  fxX.F(X)  —  the  process  X  with  X  =  F(X );  this  allows  us  to  recursively  define  processes, 

•  P/s  —  the  process  that  behaves  like  P  behaves  after  partaking  in  the  trace  s, 
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•  P\\\Q  —  the  parallel  composition  of  processes  P  and  Q  with  no  interaction  between  P  and  Q, 

•  PJ /Q  —  the  process  that  behaves  like  the  parallel  composition  of  processes  P  and  Q  with 
events  for  P’s  alphabet  made  invisible 

We  will  also  use  the  following  notation  from  [13]: 

•  («i ,  ei , . . .  en)  —  the  sequence  ei ,  ei , . . .  en ;  {)  denotes  the  empty  sequence, 

•  s  |  e  —  the  number  of  occurrences  of  event  e  in  sequence  s, 

•  s 't  —  the  catenation  of  sequences  s  and  t, 

•  y/  —  a  special  event  denoting  successful  termination;  for  example,  to  indicate  that  a  process 
completes  successfully  after  partaking  in  the  events  in  a  sequence  s,  we  say  s  ~{y/)  is  a  trace 
of  a  process, 

•  s|  A  —  the  sequence  s  with  all  elements  that  are  not  in  A  removed, 

•  #s  —  the  length  of  the  sequence  s, 

•  P°  —  the  set  of  events  in  which  process  P  is  willing  to  partake;  e  €  P°  if  and  only  if  (e)  is  a 
trace  of  P, 

•  so  —  the  first  element  of  a  sequence  s, 

•  s  —  the  reverse  of  the  sequence  s;  note  that  s0  is  the  last  element  of  s, 

•  SKIP  —  a  special  process  that  is  a  no-op  other  than  successfully  completing 

•  x  :  B  P(x)  —  a  shorthand  for: 

*l  P(*l)|...|*r  -*  P(zr) 

where  B  is  a  set  of  r  events  and  each  P(a:,)  is  the  process  to  be  executed  after  the  occurrence 

Of  X{. 

Complete  definitions  of  the  constructs  and  notation  can  be  found  in  [13]. 


2.2.1  Relation  with  State  Machines 

Before  discussing  the  advantages  and  disadvantages  of  using  CSP,  we  will  examine  the  relationship 
between  CSP  models  and  state  machine  models.  First  we  will  show  that  it  is  easy  to  translate  a 
state  machine  model  into  CSP. 

Let  the  states  of  the  model  be  sti,st2, . . .  ,stn  and  the  operations  be  opi,op2, . .  .,opm.  Suppose 
that 


Bk  =  {opfcl,...,op*j(t)} 
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is  the  set  of  operations  that  can  be  executed  from  stk  and  that  s£*if-  is  the  resulting  state  when 
operation  t  is  applied  to  stk.  For  each  :  define  a  CSP  event  OVi  to  represent  the  execution  of 
operation  *.  Then,  define  a  CSP  process  ST k  for  each  stk  as  follows: 

STk  =  OVi  :  Bk  -  STk,i 

If  stk  is  the  initial  state  of  the  system,  then  the  process  P  =  ST k  is  an  equivalent  formulation  of  the 
system  in  terms  of  CSP.  For  example,  our  CSP  model  of  the  airplane  can  be  derived  automatically 
from  our  state  machine  model  of  the  airplane  by  using  the  process  derived  above. 

Now,  we  will  consider  translating  a  CSP  model  into  a  state  machine  model.  Suppose  that  P  is  a 
CSP  process  which  models  the  system  in  question.  For  each  trace  t,  we  define: 

STt  =  {s  €  traces(P)  :  P/s  =  P/t} 

Recall  that  given  a  process  P  and  a  trace  s,  the  expression  P/s  in  CSP  denotes  the  process  that 
behaves  like  P  behaves  after  participating  in  the  events  in  s. 

So,  STt  contains  all  of  the  traces  of  P  for  which  P’s  future  behavior  is  the  same  as  P’s  future 
behavior  after  participating  in  t. 

Given  STt  and  an  event  e  of  P’s  alphabet,  consider  whether  t‘(e)  is  a  trace.  If  it  is,  then  define: 
valid{e,STt)  =  TRUE 

W  =  STt.{e) 

otherwise,  define 

valid{e,STt)  =  FALSE 

It  is  straightforward  to  show  that  this  provides  a  state  transition  function  that  is  well-defined  on 
the  set  of  states.  The  state  machine  model  obtained  is  equivalent  with  the  CSP  model  in  the  sense 
that: 

•  Any  trace  of  the  CSP  model  is  a  valid  execution  sequence  for  the  state  machine  model  and 
vice-versa. 

•  The  behavior  exhibited  by  the  CSP  model  after  participating  in  the  events  in  a  trace  t  is  the 
same  as  that  of  the  state  machine  model  when  started  in  the  state  ST t. 

Applying  this  procedure  to  the  CSP  model  of  the  airplane  results  in  states: 

•  ST<> 

*  S'l'(start) 
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*  ^ (start,  to) 

*  (start,  to,  ab) 

*  fo,  a6, /) 

with  the  following  transitions  possible: 


By  equating  the  states  and  operations  as  follows: 


•  STq  ^  PARKED 

•  ST (start)  ~  MOVING 

•  ST(Start,to)~  taking-off 

•  ST(start,to,ab)"  FLYING 

•  S? (start,  to, ab,l)~  LANDING 

•  start  «-*•  Start-Engine 

•  stop  *-+  Stop-Engine 

•  to  *-+  Take-Off 

•  ah  <-*■  In- Air 

•  l  Land 
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td  *-*■  On-Ground 


it  is  clear  that  this  is  equivalent  to  our  state  machine  model  of  the  airplane. 

Thus,  we  see  that  it  is  straightforward  to  translate  between  deterministic  processes  in  CSP  and 
state  machines.  Further  research  needs  to  be  done  to  determine  whether  the  above  construction  is 
suitable  for  nondeterministic  processes. 


2.2.2  Advantages 

Although  CSP  processes  can  be  translated  into  state  machines,  there  are  certain  advantages  to 
using  CSP.  Some  of  the  major  reasons  are  that  CSP  supports  reasoning  about  concurrency,  CSP 
facilitates  the  development  of  abstract  system  models,  and  CSP  does  not  make  any  distinction 
between  a  process  and  its  environment. 

Concurrency  can  be  represented  in  a  natural  way  by  the  parallel  composition  operator  (||)  in  CSP. 
For  example,  P\\Q  represents  P  operating  concurrently  with  Q  with  synchronization  occurring  on 
events  common  to  both  processes.  As  there  are  defined  operators  and  associated  proof  rules  for 
concurrency,  CSP  provides  direct  support  for  reasoning  about  concurrent  processing. 

Rather  than  considering  a  systems  internal  state,  CSP  considers  events  that  are  visible  external 
to  the  system.  This  makes  it  possible  to  construct  models  that  make  no  reference  to  the  internal 
structure  of  the  system.  Thus,  it  is  easy  to  construct  models  that  abstract  away  implementation 
details. 

CSP  considers  each  process’  environment  to  be  a  process  itself.  Thus,  CSP  can  be  used  to  specify 
both  a  process  and  the  environment  of  the  process.  This  makes  it  possible  to  make  assertions  about 
and  reason  about  the  environment  of  a  process. 


2.2.3  Disadvantages 

A  conscious  decision  was  made  in  the  development  of  CSP  to  ignore  the  concept  of  causality.  A 
consequence  of  this  is  that  there  is  no  way  to  specify  that  a  process  causes  an  event  to  occur. 
Processes  have  no  control  over  when  events  occur,  they  merely  partake  in  processes  that  occur. 
In  certain  parts  of  [13],  it  seems  that  the  environment  is  responsible  for  generating  events.  As 
mentioned  earlier,  the  environment  of  a  process  is  a  process  itself;  thus,  it  does  not  seem  consistent 
to  view  the  environment  as  producing  events. 

In  general,  various  aspects  of  CSP  seem  unintuitive.  This  means  that  the  formal  manipulations 
performed  in  the  analysis  of  a  CSP  model  can  violate  the  intuition  of  the  analyst  unless  the  analyst 
is  very  experienced  in  the  use  of  CSP.  This  is  discouraging  in  thatoit  results  in  a  steep  learning 
curve  for  CSP  and  makes  it  difficult  to  determine  the  correctness  of  CSP  models. 

Another  potential  problem  with  using  CSP  is  that  the  standard  mode  of  defining  processes  is  by 
using  the  process  language.  This  often  results  in  the  system  being  specified  as  the  composition 
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(using  a  variety  of  the  CSP  operators)  of  a  relatively  large  set  of  processes.  This  can  make  it  very 
difficult  to  understand  the  system’s  behavior  from  the  specification. 

In  summary,  the  main  disadvantage  of  CSP  seems  to  be  that  it  is  such  a  powerful  language  that  a 
thorough  understanding  of  CSP  is  required  to  use  it.  On  the  other  hand,  a  formalism  such  as  state 
machines  is  fairly  understandable  even  to  novices. 


2.3  PETRI  NETS 

As  with  the  other  formalisms,  there  are  several  variations  of  Petri  nets.  In  this  section,  we  will  only 
consider  the  simplest  version  of  Petri  nets.  For  a  more  complete  description  of  Petri  nets,  see  [19]. 

A  Petri  net  model  of  a  system  contains  four  components: 

•  V  —  the  set  of  places, 

•  T  —  the  set  of  transitions, 

•  X  —  a  mapping  from  transitions  to  bags  of  places, 

•  O  —  a  mapping  from  transitions  to  bags  of  places, 

Each  place  is  a  container  for  tokens.  An  assignment  of  tokens  to  places  is  called  a  marking.  Thus, 
a  marking  is  a  mapping  from  places  to  nonnegative  integers.  Suppose  that  for  transition  t,  place 
p  occurs  n  times  in  the  bag  of  places  specified  by  X(t).  Then,  if  p  is  a  marking  with  p(p)  >  n, 
then  we  say  that  t  can  fire  in  p.  When  t  fires  in  p,  tokens  are  removed  from  each  p  in  I (t);  the 
number  of  tokens  removed  is  equal  to  the  number  of  times  that  p  occurs  in  X(t).  Similarly,  tokens 
are  added  to  each  p  in  0(t);  one  token  is  added  to  p  for  each  occurrence  of  p  in  O(t). 

To  see  how  Petri  nets  can  be  used  to  model  machines  in  a  natural  fashion,  suppose  we  view  a 
machine  as  being  defined  by  events 2  and  conditions.  An  event  is  an  action  that  can  occur  in  the 
system  and  a  condition  is  a  predicate.  We  can  view  the  state  of  the  system  as  being  defined  by  a 
set  of  predicates.  Each  event  can  be  described  in  terms  of  the  conditions  that  must  hold  for  it  to 
occur,  its  preconditions ,  and  the  conditions  that  it  causes  to  hold  in  the  system,  its  postconditions. 
Then,  a  Petri  Net  representation  of  the  system  can  be  constructed  by: 

a.  Defining  a  place  for  each  condition  in  the  system. 

b.  Defining  a  transition  t  for  each  event  e  in  the  system  so  that: 

(1)  If  p  is  a  place  that  corresponds  to  a  precondition  of  e,  then  p  6  1(f). 

2In  this  section,  “event”  has  a  different  connotation  than  it  does  in  the  discussion  of  CSP. 
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(2)  If  p  is  a  place  that  corresponds  to  a  postcondition  of  e,  then  p  €  0(t). 


For  example,  consider  our  airplane  example.  The  events  are  the  system  operations  Start-Engine, 
Take-Off,  Land,  Stop-Engine,  In-Air,  and  Ground.  We  define  tata,  tto,  tt,  t3io,  tia,  and  tg  to  be  the 
transitions  corresponding  to  these  events. 

The  conditions  are  the  predicates  we  defined  in  Section  2.1.1: 

•  the  engine  is  on 

•  a  take-off  is  in  progress 

•  a  landing  is  in  progress 

•  the  plane  is  airborn 

•  the  engine  is  off 

•  a  take-off  is  not  in  progress 

•  a  landing  is  not  in  progress 

•  the  plane  is  not  airborn 


We  define  p0,  pt,  pt,  pa,  pno,  pnt,  pn!,  and  pna  to  be  the  places  corresponding  to  these  conditions. 
The  reason  it  is  necessary  to  have  the  predicates  pno,  pnt,  pni,  and  pna  is  that  the  variety  of  Petri 
Net  that  we  are  using  in  this  section  does  not  allow  a  transition  to  test  whether  a  place  is  empty. 
So,  although  it  is  clear  that  we  intend  “the  engine  is  off”  to  correspond  to  p„  being  empty,  we 
must  explicitly  ^dd  a  place  representing  “the  engine  is  off”  for  our  transitions  to  make  use  of  this 
condition. 

The  preconditions  are  simply  the  constraints  on  when  an  operation  can  be  applied.  For  example, 
since  the  plane  must  be  airborn  before  landing,  pa  is  a  precondition  for  t/.  The  postconditions  are 
derived  from  the  state  changes  caused  by  the  transition.  For  example,  since  the  engine  enters  the 
on  state  after  it  is  turned  on,  p0  is  a  postcondition  for  tsta 

The  complete  definition  of  I  and  O  is: 


t 

m 

O(t) 

tsta 

{ Pno } 

{. Po } 

tto 

{Po  i  Pnt ,  Pnl  5  Pna  } 

{Po,Pt,  Pnl i  Pna  } 

tl 

{Po>Pa»Pn/} 

{Po  j  Pna,  P/} 

tsto 

{ Po  >  Pna  ,  Pnl  ?  Pnt } 

{Pno  >  Pna  j  Pnl  ,  Pn t } 

Ua 

{Pt.Pna} 

{Pnt,  Pa} 

Js- 

{Pi} 

{. Pn /} 
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2.3.1  Relation  with  State  Machines 


Each  marking  can  be  considered  a  state  and  each  transition  can  be  considered  an  operation.  Then, 
the  state  transition  function  can  be  defined  from  Z  and  O  from  the  firing  rules  defined  above.  Thus, 
it  is  straightforward  to  map  Petri  nets  into  state  machines. 

Although  a  state  machine  can  be  translated  into  a  Petri  net  by  the  following  steps: 

a.  Define  one  place  for  each  state. 

b.  Given  st  and  op  such  that  op  can  be  executed  in  st  and  results  in  st2,  define  a  transition 
tat,0p  that  removes  a  token  from  the  place  corresponding  to  st  and  adds  a  token  to  the  place 
corresponding  to  st2- 

c.  Require  that  the  initial  marking  of  the  system  always  have  all  of  the  places  empty  except  for 
one  which  contains  a  single  token 

this  transformation  would  not  be  very  useful.  In  the  worst  case,  it  would  result  in  the  number  of 
transitions  in  the  Petri  net  being  equal  to  the  product  of  the  number  of  states  and  the  number  of 
operations  in  the  state  machine  model.  As  the  places  can  only  represent  integer  values,  it  is  not 
clear  how  a  state  machine  can  automatically  be  mapped  into  a  Petri  net  in  a  useful  way. 


2.3.2  Relation  with  Traces 

It  is  also  possible  to  think  of  the  firing  of  a  transition  as  being  an  event.  Then,  a  Petri  net  can  be 
translated  into  a  deterministic  CSP  process  as  follows: 

Say  that  s  is  a  firing  sequence  from  marking  p  in  a  Petri  net  if: 

s  consists  of  a  single  transition  t  that  can  fire  in  p,  the  initial  marking  of  the  system, 

or  i  =  ( t )  ‘sx  where  t  can  fire  in  p  and  si  is  a  firing  sequence  for  pt,  the  marking  resulting 
from  t  firing  in  p 

In  other  words,  s  is  a  possible  execution  history  of  the  Petri  net.  So,  the  traces  of  the  CSP 
process  can  be  defined  to  be  the  set  of  firing  sequences  from  po,  the  initial  marking  of  the 
Petri  net. 

As  with  state  machines,  although  it  is  possible  to  automatically  construct  a  Petri  net  from  a 
deterministic  CSP  process,  it  is  difficult  to  do  so  in  a  useful  manner. 


2.3.3  Advantages 

Petri  nets  are  useful  for  simulating  systems  due  to  the  simple  execution  rules.  They  can  also  be 
used  to  analyze  safety  properties  automatically  through  reachability  trees  (see  [19])  as  long  as  the 
number  of  transitions  is  not  too  large.  Thus,  Petri  nets  share  some  of  the  advantages  of  state 
machines. 
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As  Petri  nets  do  not  specify  the  order  of  firing  when  more  than  one  transition  can  fire  in  a  given 
marking,  they  can  be  used  to  represent  concurrency.  Thus,  they  share  some  of  the  advantages  of 
CSP. 

2.3.4  Disadvantages 

The  class  of  Petri  nets  that  we  have  described  provides  little  support  for  reasoning  about  data  flow 
in  a  system.  For  example,  it  would  be  difficult  to  model  the  reading  and  writing  of  data  values 
using  Petri  nets.  They  are  better  suited  for  reasoning  about  the  control  flow  in  a  system.  For 
example,  in  the  model  of  the  readers/ writers  problem  in  [19],  the  values  of  the  data  being  read 
and  written  are  ignored.  All  that  is  considered  is  whether  the  data  is  being  read  while  it  is  being 
written.  Thus,  the  flavor  of  Petri  nets  described  in  this  section  is  not  applicable  when  data  values 
are  relevant. 


2.4  TEMPORAL  LOGIC 

Although  there  are  several  flavors  of  temporal  logic,  we  will  only  consider  the  basic  flavor  in  this 
section.  Models  are  constructed  by  combining  predicates  using  logical  operators.  In  addition  to 
the  standard  logical  operators,  two  additional  operators  are  provided. 

a.  OP  —  denotes  that  predicate  P  is  satisfied  for  all  future  times, 

b.  OP  —  denotes  that  predicate  P  is  satisfied  for  some  future  time 

These  operators  can  be  combined  to  form  more  complicated  expressions.  For  example: 

•  OOP 

denotes  that  there  is  some  time  after  which  P  is  always  true  while 

•  OOP 

denotes  that  it  is  always  the  case  that  at  some  later  time  P  will  be  true. 


2.4.1  Relation  with  other  Formalisms 

In  general  it  is  difficult  to  relate  models  written  in  temporal  logic  with  models  written  in  formalisms 
such  as  state  machines,  CSP,  and  Petri  nets  since  there  is  very  little  structure  to  a  temporal  logic 
specification.  The  other  formalisms  provide  an  explicit  model  while  temporal  logic  provides  more 
of  an  implicit  model  by  making  assertions  about  the  behavior  of  the  system. 
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2.4.2  Advantages 


The  main  advantage  of  temporal  logic  is  that  it  allows  for  reasoning  about  temporal  properties. 
This  is  not  all  that  significant  since  it  is  possible  to  perform  similar  reasoning  in  other  formalisms 
(see  Section  3.2.1). 


2.4.3  Disadvantages 

The  main  disadvantage  of  temporal  logic  is  that  it  is  a  very  primitive  specification  language  Unlike 
state  machines,  CSP,  and  Petri  nets,  there  is  no  concept  of  processing  inherent  in  temporal  lop'c. 
This  means  that  the  developer  of  the  model  is  responsible  for  building  concepts  from  scratch.  Also, 
it  is  nontrivial  to  determine  the  completeness  and  consistency  of  a  t'mpora1  logic  specification  (just 
as  it  is  nontrivial  to  determine  the  completeness  and  consistency  of  a  process  specified  by  a  sat 
predicate  in  CSP). 

It  is  also  important  to  note  that  while  temporal  logm  can  be  used  to  si  ecify  temporal  properties,  it 
cannot  be  used  to  state  real-time  policies.  Thus,  temporal  logic  falls  very  short  of  totally  addressing 
time.  This  failure  is  partially  addressed  by  interval  temporal  logics  which  are  discussed  in  the  next 
section. 


2.5  INTERVAL  TEMPORAL  LOGIC 

Interval  temporal  logics  (ITLs)  are  flavors  of  temporal  logic  in  which  operators  are  provided  for 
specifying  intervals  of  tim  ..  Since  many  interesting  properties  are  easily  expressed  using  intervals 
of  time  I'  I-  specifications  are  often  nicer  than  temporal  logic  specifications.  For  example,  we  can 
.sert  tb  .  airplane  remains  airborn  between  when  it  takes  off  and  when  it  lands  as  follows: 

During  the  interval  of  time  between  when  the  plane  becomes  airborn  and  when  the  plane 
lands,  it  is  always  the  case  that  the  plane  is  airborn. 

It  is  difficult  to  express  assertions  about  bounded  time  intervals  in  temporal  logic  since  □  and  O  do 
not  place  any  restrictions  on  how  far  into  the  future  they  extend.  To  address  this  issue,  some  flavors 
of  temporal  logic  include  a  third  temporal  operator,  Until  that  can  be  used  to  bound  time  intervals. 
ITL  is  based  on  the  assumption  that  intervals  are  a  more  natural  way  to  specify  restrictions  on  the 
scope  of  O  and  O.  There  are  two  flavors  of  ITL.  In  this  report,  we  will  consider  the  flavor  of  ITL 
described  in  [17]. 

Assertions  in  ITL  are  of  the  form: 

{/]« 

where 

•  /  denotes  a  time  :nterval,  and 
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•  a  is  a  temporal  logic  assertion 
For  example: 

•  [I\P  asserts  that  P  is  true  at  the  first  time  in  interval  J, 

•  [/]□/>  asserts  that  P  is  true  at  every  time  in  interval  J, 

•  [1)0 P  asserts  that  P  is  true  at  some  time  in  interval  I 

Thus,  if  /  is  an  interval  that  begins  with  the  airplane  becoming  airborn  and  ends  just  prior  to  the 
airplane  landing  and  A  denotes  that  the  airplane  is  airborn,  then: 

[/]OA 

asserts  that  the  airplane  is  airborn  between  when  it  takes  off  and  when  it  lands. 

ITL  provides  the  following  constructs: 

•  Given  a  predicate  P,  [P]  denotes  an  interval  that  begins  with  P  becoming  true, 

•  *1  denotes  that  interval  I  exists, 

•  before  I  denotes  the  time  just  prior  to  the  beginning  of  I, 

•  I  =>  J  denotes  the  interval  that  starts  at  the  end  of  I  and  ends  at  the  end  of  the  next  J, 

•  I  4=  J  denotes  the  interval  that  ends  at  the  end  of  J  and  begins  at  the  end  of  the  first  I 

preceding  J 

For  example,  if  L  denotes  that  the  airplane  has  landed  and  T  denotes  that  the  airplane  is  taking 
off,  then  we  can  formalize  the  assertion  that  the  airplane  is  airborn  between  when  it  takes  off  and 
when  it  lands  as: 

•  [(P  =>  A)  =>  beforeL]A 

[17]  also  defines  the  following  constructs  to  address  real-time: 

•  /  =>•  /  +  t  denotes  an  interval  of  length  t  starting  at  the  beginning  of  interval  /, 

•  J  -  t  =>  I  denotes  an  interval  of  length  t  ending  at  the  beginning  of  interval  /, 

•  [/]<  t  denotes  that  the  length  of  interval  I  is  less  than  t, 
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•  [/]>  t  denotes  that  the  length  of  interval  I  is  greater  than  t 
For  example, 

♦  [A  =>  beforeT}<  10 hours 

asserts  that  an  airplane  must  always  land  within  10  hours  of  when  it  becomes  airborn. 

2.5.1  Relation  with  other  Formalisms 

Since  ITL  is  a  flavor  of  temporal  logic  the  discussion  in  Section  2.4.1  is  also  relevant  to  ITL. 


2.5.2  Advantages 

The  only  advantage  that  ITL  has  over  other  formalisms  is  that  it  allows  for  the  statement  of 
temporal  and  real-time  properties.  Although  many  other  formalisms  can  be  used  to  state  temporal 
properties,  there  are  few  formalisms  that  can  be  used  to  state  real-time  properties.  Also,  as  many 
interesting  temporal  properties  are  statements  about  intervals  in  time,  ITL  sometimes  allows  for  a 
more  natural  specification  than  might  be  possible  in  other  formalisms. 


2.5.3  Disadvantages 

As  with  temporal  logic,  there  is  no  inherent  notion  of  processing  in  ITL.  So,  ITL  does  not  provide 
much  support  for  the  specification  of  processes  either. 

Another  disadvantage  is  that  no  proof  rules  are  provided  for  ITL  in  [17].  Instead  it  is  suggested 
that  a  decision  process  be  used  to  automatically  analyze  ITL  specifications.  Although  [17]  claims 
that  ITL  is  decidable,  it  is  not  clear  whether  an  efficient  decision  procedure  exists  for  ITL.  If  the 
decision  process  is  not  efficient,  then  it  is  not  reasonable  to  perform  the  analysis  automatically  and 
it  is  necessary  to  have  proof  rules  for  the  logic. 

If  there  is  an  efficient  decision  process,  then  the  fact  that  the  analysis  can  be  done  automatically 
would  be  an  advantage.  If  not,  then  it  is  necessary  to  determine  whether  useful  proof  rules  can  be 
derived  for  ITL  before  using  it  to  model  systems. 


2.6  REAL  TIME  LOGIC 

Real  Time  Logic  (RTL)  is  described  in  [6].  Rather  than  having  the  □  and  O  operators  it  makes 
use  of  an  explicit  notion  of  time  and  expressions  quantified  over  time.  For  example,  DP  can  be 
represented  as: 
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Vt,P(i) 


RTL  is  consistent  with  CSP  in  that  it  contains  the  notions  of  events  and 
processes.  RTL  distinguishes  between  the  following  classes  of  events: 

•  Start  Events  —  f  P  denotes  the  start  of  execution  of  process  P, 

•  Stop  Events  —  f  P  denotes  the  completion  of  execution  of  process  P, 

•  Transition  Events  —  (5  :=  T)  denotes  the  changing  of  value  of  predicate  S  to  true  while 
( S  :=  F)  denotes  the  changing  of  value  of  predicate  S  to  false 

•  External  Events  —  events  that  cannot  be  caused  to  happen  by  the  system 

RTL  uses  the  @  operator  to  define  the  time  of  the  ith  occurrence  of  an  event.  Given  an  event  e  and 
a  positive  integer  t: 

•  @(e,i) 

denotes  the  time  at  which  the  ith  occurrence  of  e  occurs.  If  we  view  A  as  a  state  predicate  that 
denotes  whether  the  airplane  is  airborn  and  G  as  a  state  predicate  that  denotes  whether  the  airplane 
is  on  the  ground,  the  assertion: 

Vi,  t  such  that  ©((A  :=  T),  i)  <  t  <  «(( G  :=  T),  i  +  1)  :  A(t) 

specifies  that  the  airplane  remains  airborn  between  when  it  takes  off  and  when  it  lands.  The  reason 
that  we  are  interested  in  occurrence  i+1  of  (G  :=  T)  rather  than  occurrence  i  is  that  we  assume  that 
the  plane  is  initially  on  the  ground.  Thus,  (G  :=  T)  is  assumed  to  happen  at  time  0.  Consequently, 
the  ith  occurrence  of  (G  :=  T)  will  always  precede  the  ith  occurrence  of  (A  :=  T). 


2.6.1  Relation  with  other  Formalisms 

RTL  seems  to  combine  aspects  of  various  formalisms.  Since  RTL  contains  the  notion  of  state 
predicates,  it  is  possible  to  use  RTL  in  such  a  way  that  it  is  similar  to  the  state  machine  paradigm. 
Similarly,  since  RTL  contains  the  notion  of  processes  and  events,  it  can  be  used  in  ways  that  are 
similar  to  CSP.  There  are  also  similarities  between  RTL  and  ITL.  For  example,  ITL  treats  the 
changing  of  a  predicate’s  value  as  an  event  just  as  RTL  does. 


2.6.2  Advantages 

Since  RTL  incorporates  aspects  of  many  other  formalisms,  it  shares  most  of  the  advantages  of  the 
other  formalisms.  For  example,  it  addresses  concurrency  and  real-time  and  provides  models  that 
are  understandable  yet  free  from  implementation  detail. 
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2.6.3  Disadvantages 


If  real-time  is  not  a  concern,  then  there  is  no  advantage  to  using  RTL  instead  of  CSP.  In  fact,  there 
is  an  advantage  in  using  CSP  in  that  the  process  language  for  CSP  in  much  richer  than  that  for 
RTL. 

There  are  often  times  when  it  is  difficult  to  say  simple  things  in  RTL.  For  example,  whereas  ITL 
allows  us  to  refer  to  the  interval  of  time  between  when  the  plane  becomes  airborn  and  the  first 
subsequent  time  the  plane  lands,  RTL  forces  us  to  know  which  occurrence  of  ( G  :=  T )  occurs  next. 
From  the  design  of  our  system  we  happened  to  know  that  occurrence  i  +  1  of  G  :=  T  is  the  first 
occurrence  subsequent  to  @((A  :=  there  are  times  when  it  is  very  difficult  to  determine 

which  occurrence  occurs  next.  A  related  issue  is  that  if  we  changed  our  system  to  require  that  the 
airplane  be  airborn  at  time  0,  then  our  assertion  would  have  to  be  changed  to: 

Vt,i  such  that  @((A  :=  T),i)  <  t  <  :=  T),i)  :  A(t) 

This  can  result  in  the  specifications  being  difficult  to  maintain.  For  example,  a  change  in  an  initial 
condition  might  result  in  many  changes.  It  also  requires  information  to  be  included  in  the  problem 
that  is  not  necessarily  relevant  to  the  problem.  For  example,  is  it  necessary  to  know  whether  the 
airplane  was  initially  on  the  ground  in  order  to  determine  whether  it  is  always  airborn  between 
when  it  takes  off  and  when  it  lands. 


2.7  SUMMARY 

In  this  section  we  summarize  the  results  of  our  formalism  study  by  discussing  the  problem  domains 
to  which  each  formalism  is  appropriate.  Because  of  the  strong  connections  between  the  various 
formalisms,  it  is  usually  the  case  that  anything  that  can  be  done  using  one  formalism  can  be  done 
using  an  appropriate  variety  of  any  other  formalism.  So,  in  the  following  we  consider  a  formalism 
to  be  appropriate  for  a  problem  domain  only  when  it  can  be  used  in  a  straightforward  way  to  obtain 
useful  results  about  the  problem  domain. 

Our  formalism  study  found  CSP  to  be  the  most  reasonable  formalism  for  C2  systems  when  real¬ 
time  is  not  an  issue.  When  real-time  is  an  issue,  CSP  does  not  appear  to  be  appropriate.  Then,  a 
formalism  such  as  ITL  or  RTL  is  needed.  It  is  not  clear  that  either  of  ITL  and  RTL  is  superior  to 
the  other.  Our  specific  findings  about  each  formalism  are  summarized  in  the  following  table. 


Formalism 

Most  Appropriate  Problem  Domain 

State  Machines 

Stand-alone  transaction  processing  systems 

Traces 

Distributed  systems  which  interact  with  their  environment 

Petri  Nets 

Policies  with  control  flow  more  important  than  the  data  flow 

Temporal  Logic 

Systems  with  temporal  policies 

Interval  Temporal  Logic 

Systems  with  real-time  policies 

Real  Time  Logic 

Systems  with  real-time  policies 
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2.7.1  State  Machines 


As  the  state  machine  paradigm  does  not  address  concurrency  very  well,  it  is  more  suited  to  stand¬ 
alone  systems  than  it  is  to  distributed  systems.  As  the  transitions  represent  operations,  the  state 
machine  paradigm  most  naturally  fits  with  systems  that  accept  inputs  and  provide  responses  to 
those  inputs. 

Thus,  state  machines  are  most  appropriate  to  stand-alone,  transaction  processing  systems.  They 
are  least  appropriate  for  distributed  systems  that,  in  addition  to  accepting  input,  actively  request 
information  from  their  environment.  For  example,  in  our  model  of  an  airplane,  it  is  unnatural  to 
view  the  event  when  the  airplane  becomes  airborn  as  an  operation. 

As  there  is  a  strong  connection  between  addressing  real-time  and  addressing  concurrency,  state 
machines  do  not  appear  to  be  appropriate  for  reasoning  about  real-time. 


2.7.2  Traces 

As  CSP  has  a  steeper  learning  curve  than  state  machines,  it  is  less  appropriate  for  the  stand-alone, 
transaction  processing  systems  that  state  machines  address  adequately.  This  does  not  mean  that 
CSP  cannot  be  used  for  such  systems,  it  just  means  that  CSP  might  be  overkill  in  these  cases. 

Of  the  formalisms  we  examined,  CSP  seems  the  most  appropriate  for  distributed  systems  that 
actively  query  the  state  of  the  environment.  As  these  are  defining  characteristics  of  C2  systems, 
we  feel  that  CSP  is  the  most  appropriate  formalism  to  use  in  the  portions  of  this  report  that  ignore 
real-time  issues.  The  variety  of  CSP  defined  in  [13]  does  not  address  real-time  and  thus  is  not 
appropriate  for  systems  in  which  real-time  issues  are  important. 

We  have  studied  proposals  for  adding  real-time  to  CSP  and  investigated  adding  real-time  to  CSP 
ourselves  and  reached  the  conclusion  that  it  is  very  difficult  to  extend  CSP  to  address  real-time. 
The  main  cause  of  the  problem  is  that  since  events  simply  occur  rather  than  being  generated  by 
anything,  it  is  difficult  to  define  semantics  that  allow  for  the  specification  that  an  event  must  occur 
at  a  specific  time  while  remaining  consistent  with  the  semantics  already  defined  for  CSP. 


2.7.3  Petri  Nets 

Since  Petri  nets  do  not  address  data  flow  very  well,  they  are  only  useful  when  control  flow  is  more 
important  than  data  flow  in  the  system  policy.  Since  Petri  nets  can  be  translated  into  CSP  and 
CSP  addresses  control  flow  very  nicely,  we  see  no  reason  to  use  Petri  nets  for  formalizing  security 
and  denial  of  service  concepts.  If  it  is  desirable  to  perform  a  simulation  of  the  system,  then  it  might 
be  reasonable  to  construct  a  Petri  net  model  of  the  system  for  simulation  purposes.  The  Petri  net 
model  could  then  be  translated  into  CSP  for  the  formal  analysis. 
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2.7.4  Temporal  Logic 


Since  temporal  properties  can  be  stated  in  other  formalisms  and  temporal  logic  provides  very  little 
structure  for  constructing  system  models,  we  see  no  reason  to  use  temporal  logic  for  formalizing 
security  and  denial  of  service  concepts.  Instead,  it  seems  more  reasonable  to  derive  operators  in 
the  other  formalisms  that  correspond  to  the  temporal  operators  in  temporal  logic.  For  example,  in 
Section  3.2.1  we  discuss  defining  the  concept  of  eventuality  in  the  CSP  formalism. 


2.7.5  Interval  Temporal  Logic 

Since  temporal  properties  can  be  addressed  in  other  formalisms,  ITL  appears  to  only  be  appropriate 
for  addressing  real-time  systems. 


2.7.6  Real  Time  Logic 

Since  RTL  does  not  provide  as  rich  of  a  process  language  as  CSP,  there  is  no  point  in  using  RTL 
unless  real-time  issues  are  relevant.  Although  RTL  can  be  used  to  address  real-time  systems, 
there  are  times  that  it  might  result  in  unwieldy  specifications  due  to,  for  example,  the  need  to 
explicitly  specify  which  occurrence  of  an  event  is  of  concern  rather  than  simply  referring  to  the 
next  occurrence.  In  these  cases,  ITL  is  more  appropriate  to  use  than  RTL.  Otherwise,  it  is  more 
appropriate  to  use  RTL  than  ITL  because  it  is  more  readable. 
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SECTION  3 


AVAILABILITY  MODELS 


In  this  section  we  describe  availability  models  for  C2  systems.  First,  we  formalize  the  notion  of 
fault  tolerance.  Next,  we  formalize  certain  classes  of  service  policies.  In  analyzing  a  system,  we 
would  first  use  the  fault  tolerance  policy  developed  in  Section  3.1  to  determine  whether  the  system 
behaved  as  specified  even  in  the  presence  of  specified  classes  of  faults.  Then,  we  would  analyze  the 
system  specifications  with  regard  to  the  service  policies  developed  in  Section  3.2.  This  analysis 
will  determine  whether  the  system  satisfies  the  service  policies  even  in  the  presence  of  the  specified 
classes  of  faults. 


3.1  A  MODEL  FOR  FAULT  TOLERANCE 

The  following  terminology  is  used  throughout  this  section: 

•  A  failure  is  a  deviation  between  the  specified  behavior  of  an  entity  and  its  observed  behavior. 

•  A  fault  is  the  phenomenological  cause  of  a  failure. 

Our  model  of  fault  tolerance  is  based  on  the  description  found  in  [2].  The  entire  system  is  viewed 
as  a  hierarchy  of  subsystems.  Each  subsystem  represents  a  server  that  provides  a  service  to  a 
client  (or  user).  To  provide  this  service,  the  subsystem  must,  in  turn,  request  service  from  lower 
level  subsystems,  which  may  be  software  or  hardware  components  of  the  system.  These  lower  level 
subsystems  are  called  resources  for  the  server,  and  the  server  is  said  to  depend  on  those  resources 
that  it  directly  invokes.  A  particular  subsystem  can  be  thought  of  as  either  a  client,  server  or 
resource  depending  on  the  level  at  which  the  subsystem  is  being  viewed.  Hardware  subsystems  can 
also  be  viewed  as  part  of  this  hierarchy,  and,  in  general,  appear  in  the  hierarchy  at  the  lower  levels. 
Figure  3-1  represents  one  level  of  the  hierarchy.  The  arrows  in  the  figure  represent  requests  and 
responses  between  clients  and  the  server  and,  at  the  next  lower  level  where  the  server  is  the  client, 
between  the  server  and  its  resources. 

Failures  may  occur  at  any  level  within  any  subsystem,  either  hardware  or  software,  of  the  hierarchy. 
A  classification  of  the  types  of  failures  that  might  occur  is  given  in  section  3.1.1.  When  a  resource 
that  a  server  depends  upon  experiences  a  failure  whose  consequences  are  propagated  to  the  server, 
then  a  fault  has  occurred  for  the  server.  The  manner  in  which  the  server  handles  the  fault  and  the 
number  and  types  of  faults  that  the  server  can  adequately  handle  determine  the  degree  to  which 
the  server  is  fault  tolerant.  Faults  that  a  server  cannot  adequately  handle  are  propagated  upward 
to  the  server’s  clients  as  failures  of  the  server,  of  a  possibly  different  type. 
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Figure  3-1.  The  System  Server  Model 
3.1.1  Representing  Failures  in  the  Model 

A  server’s  specifications  define  the  correct  operation  of  the  server  in  response  to  an  input.  Failures 
correspond  to  incorrect  behavior  by  the  server  in  response  to  an  input.  In  [2]  a  classification  of 
types  of  failures  that  a  server  can  experience  is  given.  This  section  contains  a  summary  of  this 
classification.  Specific  examples  of  each  type  of  failure  are  given  in  section  3.1.3. 

A  server’s  specification  is  assumed  to  define  both  the  server’s  response  to  a  given  input  in  a  given 
state  and  the  time  interval  during  which  the  response  should  occur.  The  response  includes  both 
the  output  that  is  returned  to  the  client  and  any  state  changes  that  result. 

Response  failures  occur  when  the  response  of  the  server  is  not  correct.  There  are  two  ways  in 
which  the  response  may  fail  to  be  correct. 

•  A  value  failure  occurs  if  the  output  returned  to  the  client  is  not  correct. 

•  A  state  transition  failure  occurs  if  the  state  does  not  change  in  the  manner  specified. 

Note  that  a  response  failure  may  involve  both  a  value  failure  and  a  state  transition  failure. 
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Timing  failures  occur  when  the  response  is  correct  but  does  not  take  place  within  the  time 
interval  specified.  This  could  happen  either  because 

•  the  response  is  too  early,  or 

•  the  response  is  too  late  -  a  performance  failure. 

Omission  failures  occur  when  the  server  fails  to  respond  at  all  to  an  input. 

Crash  failures  occur  when  the  server  no  longer  responds  to  any  input  until  the  system  is  restarted. 
Crash  failures  can  be  classified  depending  on  the  manner  in  which  the  system  is  restarted. 

•  A  halting  crash  occurs  when  the  system  cannot  be  restarted. 

•  A  total  amnesia  crash  occurs  if  the  server  must  be  restarted  in  a  predefined  initial  state 
that  is  not  dependent  on  any  inputs  that  occurred  before  the  crash. 

•  A  partial  amnesia  crash  occurs  if  the  server  is  restarted  in  a  state  that  is  a  combination 
of  portions  of  the  state  before  the  crash  and  portions  of  a  predefined  initial  state. 

•  A  pause  crash  occurs  if  the  server  is  restarted  in  the  state  prior  to  the  crash. 

3.1.2  A  Definition  of  Fault  Tolerance 

In  order  to  state  a  formal  definition  of  fault  tolerance,  we  use  the  trace  semantics  of  Hoare’s 
CSP  [13].  In  this  formalism,  the  behavior  of  a  system  is  completely  specified  by  its  set  of  possible 
traces.  The  definition  can  then  be  stated  in  terms  of  conditions  on  the  set  of  traces.  Since  the 
definition  deals  with  faults,  we  need  to  specifically  identify  which  events  correspond  to  faults  and 
which  correspond  to  the  requests  and  responses  between  the  server  and  its  clients. 

A  system  (server)  is  defined  by  a  tuple  ( E,F,I,0,Tr )  where 

•  E  represents  the  set  of  possible  events  in  the  system. 

•  F  represents  the  subset  of  E  that  consists  of  all  those  events  which  are  faults. 

•  /  represents  the  subset  of  E  that  consists  of  all  those  events  that  are  “requests  for  service” 
from  the  system. 

•  O  represents  the  subset  of  E  that  consists  of  all  those  events  that  are  responses  from  the 
system  to  requests  for  service. 
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Tr  represents  the  set  of  traces  of  the  system.  Tr  is  a  subset  of  E *  and  defines  the  possible 
behavior  of  the  system. 


In  terms  of  figure  3-1,  if  the  system  is  the  server,  then  E  represents  the  possible  events  that  the 
server  can  perform  and  Tr  the  set  of  sequences  of  events.  I  represents  possible  requests  that  the 
clients  can  make  on  the  server  and  O  the  possible  responses  to  these  requests  that  the  server  can 
make.  The  set  E  includes  the  events  I,  0,  events  internal  to  the  server,  and  events  describing 
the  interaction  between  the  server  and  lower  level  resources  that  it  depends  on.  These  events  are 
subsets  of  the  input  and  output  events  of  the  lower  level  servers.  The  set  F  must  include  all  of  the 
faults  that  are  to  be  addressed  in  the  analysis.  For  example,  if  the  analysis  is  meant  to  address 
hardware  failures,  then  F  would  be  defined  to  contain  those  responses  that  the  server  receives  from 
lower  level  services  that  can  be  classified  as  failures. 

The  fault  tolerance  of  the  server  can  be  measured  in  terms  of  the  degree  to  which  it  can  tolerate 
faults  from  its  lower  level  resources  and  still  return  the  appropriate  responses  to  its  clients.  In  order 
to  analyze  the  behavior  of  the  server  in  the  presence  of  different  faults,  we  will  consider  traces  on 
the  system  that  contain  these  faults.  Such  traces  are  called  fault  scenarios.  The  intuition  behind 
this  approach  is  that  if  the  server  is  fault  tolerant,  then  the  observable  behavior  of  the  server  in 
the  trace  after  the  fault  appears  should  be  no  different  from  the  observable  behavior  of  the  server 
if  the  fault  did  not  occur. 

Following  [22]  we  define  a  fault  scenario  C  as  a  subset  of  E *.  We  make  the  additional  restriction 
that  C  be  closed  under  the  prefix  operation3.  This  means  that  C  describes  a  subset  of  the  traces  of 
the  system.  We  use  N  to  denote  the  set  of  all  traces  of  the  system  that  have  no  faults  in  them;  that 
is ,  N  =  Trf\(E  -  F)*.  Since  we  are  only  concerned  with  the  manner  in  which  the  system  handles 
faults,  we  will  assume  that  all  fault  scenarios  C  discussed  have  N  as  a  subset.  Fault  scenarios  may 
be  defined  in  a  number  of  ways.  For  example,  C  may  be  the  set  of  all  traces  that  have  at  most  one 
fault,  or  the  set  of  all  traces  whose  only  faults  are  omission  faults. 

Definition:  A  server  system  S  is  fault  tolerant  with  respect  to  a  given  fault  scenario  C  if  the 
behavior  of  5' as  observed  by  its  clients  is  unaffected  by  any  faults  that  occur  in  C. 

More  formally, 

Definition  3.1  If  (5  £  C,  then  87  £  N  $  P\IO  =  71 10,  where  10  =  I  U  O  and  |  denotes  the 
restriction  operator. 

While  the  faults  that  the  resources  may  generate  cover  all  classes  of  faults  described  in  section  3.1.1 
including  timing  faults,  it  should  be  noted  that  our  trace  model  has  no  way  of  specifying  exact 
time.  In  particular,  if  a  response  time  requirement  exists  for  the  server,  this  definition  has  no  way 
of  addressing  whether  or  not  that  requirement  is  satisfied.  The  definition  does  address  temporal 
order,  however,  and  if,  in  the  presence  of  a  fault,  the  server’s  responses  are  identical  but  occur  in  a 
different  sequence,  this  behavior  is  identified  by  the  definition  as  behavior  that  is  not  fault  tolerant. 

3A  set  S  of  sequences  is  said  to  be  closed  under  the  prefix  operation,  or  prefix  closed,  if  t  €  S  whenever  s  €  S  and 
t  is  an  initial  subsequence  of  s 
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Adding  response  time  requirements  to  the  definition  would  involve  using  a  temporal  model  and 
had  some  notion  of  causality.  This  is  an  area  for  future  research.  Another  area  for  future  research 
is  the  investigation  of  fault  tolerance  for  systems  that  are  nondeterministic  in  the  sense  of  [13]. 
Since  our  definition  only  refers  to  the  traces  of  the  system  and  the  nondeterministic  processes 
cannot  be  characterized  solely  in  terms  of  traces,  it  is  clear  that  our  definition  does  not  address  the 
nondeterministic  processes. 

Note  also  that  this  definition  does  not  capture  a  stochastically  recognizable  change  in  behavior  of 
the  system  that  may  occur  in  the  presence  of  nondeterminism.  For  example,  suppose  that  given  a 
certain  sequence  of  inputs,  if  there  is  no  fault,  then  output  o\  is  observed  with  probability  p  and  02 
with  probability  1  —  p.  If  a  fault  occurs,  then  output  Oi  is  observed  with  probability  p'  and  02  with 
probability  1  —  p'  where  p  and  p'  are  sufficiently  different  that  the  change  is  noticeable.  This  type 
of  change  in  behavior  is  allowed  by  the  above  definition  of  fault  tolerance.  While  such  a  change 
in  behavior  is  of  concern  when  the  security  of  the  system  is  analyzed,  it  would  only  be  of  concern 
in  a  fault  analysis  of  the  system  if  the  probabilities  of  the  various  outputs  are  part  of  the  system’s 
specifications.  By  changing  the  probabilities  at  which  the  outputs  occur,  it  may  be  possible  that 
the  system’s  specifications  are  no  longer  satisfied.  This  amounts  to  the  lower  level  fault  resulting 
in  the  server  displaying  a  different  type  of  failure.  Developing  a  model  that  includes  stochastic 
behavior  is  beyond  the  scope  of  the  current  contract,  but  is  an  interesting  area  for  future  research. 

Our  definition  of  fault  tolerance  is  a  refinement  of  that  given  in  [22]  and  [3].  In  those  papers  fault 
tolerance  is  defined  as  follows: 

Definition  3.2  V/?  £  TV,/?  €  C  =>  (3\F  €  TV,  where  F  denotes  the  complement  of  F  in  E. 

The  main  differences  between  this  definition  and  Definition  3.1  are  that  Definition  3.1  explicitly 
identifies  those  events  that  are  involved  in  determining  whether  a  server  is  fault  tolerant,  and  it 
also  allows  internal  events,  that  may  take  place  in  the  server  when  recovering  from  faults,  to  be 
part  of  the  model.  The  following  example  illustrates  this  point. 

Example:  In  this  example  we  use  e,  to  denote  events  that  are  internal  to  the  system  but  not 
failures  and  /,  to  denote  internal  events  that  are  failures. 

Suppose  that  7  =  (iie^oi)  is  in  Tr  and  is  the  behavior  of  the  system,  given  input  i'i,  when 
a  fault  does  not  occur.  Suppose  that  f3  =  (iie1/1e3e4oi)  is  in  C  and  is  the  behavior  of  the 
system  when  a  fault  does  occur.  As  far  as  the  client  is  concerned,  the  system  tolerates  the 
fault  fi  since  for  an  input  of  i j,  an  output  of  ot  is  received  regardless  of  whether  or  not  the 
fault  occurs. 

Then  71 10  =  (5\  10  so  the  definition  of  fault  tolerance  given  in  Definition  3.1  is  not  violated. 
However,  fl\F  =  {i\e\eze^o\) ,  which  is  not  a  trace,  so  Definition  3.2  is  not  satisfied. 


3.1.3  Modeling  a  Fault  Tolerant  System 

In  this  section  we  discuss  an  example,  based  on  Example  1  in  [12],  and  show  how  the  various 
concepts  and  definitions  apply  to  it.  This  example  involves  a  cab  company  in  which  customers 
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telephone  their  requests  into  dispatchers  who  assigned  priorities  to  the  requests  and  placed  them 
into  a  priority  queue  for  servicing.  When  drivers  become  available,  they  are  dispatched  to  pick  up 
the  customer  in  the  queue  with  the  highest  priority.  In  order  to  increase  the  dependability  of  the 
service,  the  priority  queue  is  replicated  at  several  sites  throughout  the  city. 

In  our  discussion  of  the  example,  we  will  use  the  same  scenario.  However,  it  should  be  apparent 
that  the  example  could  easily  be  rephrased  in  a  C2  setting. 

In  terms  of  the  server  model  for  fault  tolerance,  the  clients  are  the  customers,  the  inputs  to  the 
system  are  the  customer  requests  for  service  and  the  outputs  are  the  dispatching  of  drivers  to  service 
the  request.  The  system  itself  is  a  logical  entity  that  relies  on  the  information  available  from  each 
site  and  driver.  So  these  sites  and  drivers  represent  the  resources  that  the  system  depends  upon. 
The  internal  events  involve  keeping  track  of  the  status  of  the  drivers,  polling  the  various  sites  for 
information  and  sending  information  to  them. 

The  service  is  fault  tolerant  if  each  request  is  serviced  by  exactly  one  driver  in  the  order  that  is 
determined  by  the  priority  of  the  request.  The  internal  events  include  the  actions  taken  within  the 
dispatching  system  to  assign  priorities  to  requests,  to  insert  the  requests  properly  into  the  priority 
queue  and  to  maintain  the  queue  in  a  consistent  manner  across  the  replicated  sites. 

Failures  that  might  occur  include  individual  sites  crashing  or  a  failure  in  communication  among 
the  sites  causing  the  replicated  queues  to  become  inconsistent. 

The  system  performs  two  operations  in  managing  the  customer  queue:  enqueuing  a  request,  when 
a  call  from  a  customer  arrives,  and  dequeuing  a  request  when  a  driver  is  dispatched  to  service 
a  request.  Both  the  enqueue  and  dequeue  requests  require  communication  between  the  sites  to 
maintain  the  queue  in  the  appropriate  manner.  The  sites  that  are  notified  of  an  enqueue  request 
constitute  the  final  enqueue  quorum  for  the  request;  when  a  driver  is  available,  the  sites  that  are 
queried  to  determine  which  customer  should  be  picked  up  constitute  the  initial  dequeue  quorum; 
and  the  sites  that  are  notified  when  a  driver  is  dispatched  to  pick  up  a  customer  constitute  the  final 
dequeue  quorum.  In  order  to  guarantee  that  the  queue  is  maintained  as  a  one-copy  serializable 
version  of  a  replicated  priority  queue,  it  has  been  shown  [11]  that  the  following  conditions  must 
hold: 


a. .  Each  initial  dequeue  quorum  intersects  each  final  enqueue  quorum. 

b.  Each  initial  dequeue  quorum  intersects  each  final  dequeue  quorum. 

Now  assume  that  the  cab  system  operates  as  follows.  When  a  customer  places  a  call  to  a  particular 
site,  that  site  enqueues  the  request  in  its  version  of  the  priority  queue  and  broadcasts  a  message 
to  all  the  other  sites  with  the  information.  The  sites  that  receive  the  enqueue  message  update 
their  priority  queues  accordingly,  and  these  sites  constitute  the  final  enqueue  quorum.  If  there 
are  no  failures,  the  final  enqueue  quorum  should  be  all  of  the  sites.  Similarly  when  a  particular 
site  is  notified  that  a  driver  is  available  to  be  dispatched,  then  it  dispatches  the  driver  to  the  first 
customer  in  its  priority  queue  and  then  broadcasts  this  information  to  all  the  other  sites.  The 
sites  that  receive  the  dequeue  message  update  their  priority  queues  accordingly,  and  these  sites 
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constitute  the  final  dequeue  quorum.  The  initial  dequeue  quorum  for  each  site  is  just  the  site  itself 
since  no  other  sites  were  queried  as  to  which  customer  to  service. 

(We  assume  that  the  broadcasts  require  a  fixed  amount  of  time  and  that  after  broadcasting  the 
dequeue  information,  the  site  waits  to  make  sure  that  no  dequeue  request  is  received  from  another 
site  for  the  same  customer.  If  such  a  dequeue  request  is  received,  then  some  procedure  exists  for 
determining  which  site  makes  the  dispatch.) 

The  particular  classes  of  failures  can  appear  in  the  system  in  the  following  way  when  requests  are 
made  of  the  resources. 

•  A  broadcast  message  that  is  garbled  upon  receipt  represents  a  value  failure. 

•  An  error  at  a  site  in  recording  a  correctly  received  broadcast  message  from  another  site 
represents  a  state  transition  failure. 

•  A  broadcast  message  that  takes  longer  than  the  allocated  amount  of  time  represents  a  per¬ 
formance  failure.  (There  are  no  cases  of  early  timing  failures  in  this  example.) 

•  Inability  to  broadcast  a  message  from  a  site  represents  an  omission  failure. 

•  The  complete  failure  of  a  site  or  several  sites  represents  a  crash  failure. 

•  If  all  of  the  site’s  current  state  is  destroyed  as  a  result  of  the  crash,  including  its  version  of  the 
priority  queue  and  any  knowledge  of  requests  received  or  dispatches  made  by  the  site  prior  to 
the  crash,  then  this  represents  a  total  amnesia  crash. 

•  If  a  site’s  priority  queue  can  be  restored  on  restart,  but  the  most  recent  request  or  dispatch 
is  lost,  then  this  represents  a  partial  amnesia  crash. 

•  A  failure  in  the  communications  system  at  a  site  represents  a  pause  crash  since  the  state  of 
the  site  will  be  the  unchanged  when  communications  are  restored. 

If  no  failures  occur,  then  conditions  a  and  6  will  be  satisfied  and  the  customer’s  requests  will 
be  serviced  properly.  Suppose,  however,  that  a  site  does  not  receive  an  enqueue  broadcast  from 
another  site.  The  effect  would  be  that  this  request  would  not  get  enqueued  in  the  priority  queue 
of  other  site.  As  a  consequence,  the  other  site  would  never  dispatch  a  driver  to  service  the  request 
represented  by  the  enqueue  broadcast  and  this  request  might  get  serviced  out  of  its  priority  order. 
Similarly,  if  the  site  did  not  receive  a  dequeue  broadcast  from  another  site,  then  it  would  not  know 
that  the  particular  request  was  already  serviced.  In  this  case  it  might  dispatch  another  driver  to 
service  the  request. 

In  both  cases,  the  system  is  not  fault  tolerant,  and,  as  expected,  does  not  satisfy  our  definition  of 
fault  tolerance.  To  see  this,  we  need  to  consider  possible  traces  of  the  system.  Suppose  that 

•  iXA  represents  the  initial  request  x  by  a  customer  to  site  a; 

•  ifcr,a6  represents  the  successful  broadcast  of  request  x  from  site  a  to  site  6,  for  b  ^  a; 

•  ifx.ab  represents  the  failed  broadcast  of  request  x  from  site  a  to  site  6,  for  b  ^  a; 
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•  oXi0  represents  the  dispatching  of  a  driver  to  handle  request  x  by  a  given  site  a; 

•  obx  ab  represents  the  successful  broadcast  of  a  dispatch  for  request  x  from  site  a  to  site  6,  for 
6  #  a; 

•  ofx,ab  represents  the  failed  broadcast  of  a  dispatch  for  request  x  from  site  a  to  site  6,  for  b  ^  a. 

Then  (5  =  (ix,i  ifcx> t2  ibXt\3  ox< 2  o6x2i  ofXt 23  oXi3)  is  a  possible  trace  of  the  system  in  which  two 
drivers  are  dispatched  to  service  the  same  request.  This  behavior  occurs  because  the  broadcast 
message  that  site  2  sent  to  site  3  indicating  that  site  2  had  already  sent  a  driver  to  handle  request 
x  was  not  received  by  site  3.  Hence,  site  3  thinks  that  the  request  x  has  still  not  been  handled  and 
dispatches  a  driver.  In  this  case,  0\IO  =  (ix,  1  oX(2  oXi3)  which  is  not  equal  to  7I 10  for  any  7  €  iV. 

Similarly,  if  the  priority  given  to  a  request  is  based  on  servicing  the  requests  in  the  order  received, 
then  (3  =  (t'x>  1  ibXi j2  i/x,  13  iv, 3  ibVt 31  i  fy t32  oy< 3)  is  a  possible  trace  of  the  system  in  which  the  requests 
are  serviced  out  of  order.  This  occurs  because  the  broadcast  message  that  site  1  sent  to  site  3 
indicating  that  request  x  had  been  received  was  not  received  by  site  3.  Hence,  when  request  y 
arrives,  site  3  believes  that  this  is  the  most  recent  request  and  dispatches  a  driver  to  handle  it.  In 
this  case,  (3\IO  =  (tXii  iv< 3  oVi3)  which  is  not  equal  to  71 10  for  any  7  6  N. 

One  way  of  adding  fault  tolerance  to  the  system  would  be  to  enlarge  the  initial  dequeue  quorum. 
This  could  be  done  by  requiring  a  site  to  request  information  on  who  to  dequeue  from  2n  +  1  other 
sites,  and  then  acting  on  the  majority  response.  Such  a  system  could  tolerate  n  broadcast  failures 
of  the  type  in  the  previous  examples.  An  additional  complication  occurs,  however,  because  of  the 
possibility  that  the  messages  that  are  sent  in  order  to  determine  an  initial  dequeue  quorum  might 
also  fail.  A  possible  approach  might  be  for  a  site  to  send  2n  +  1  messages  requesting  information 
and,  after  a  certain  period  of  time,  if  a  majority  of  responses  that  agreed  with  one  another  had 
not  been  received,  to  resend  messages  to  the  sites  that  had  not  yet  responded.  The  resending 
of  messages  could  be  done  as  often  as  needed.  In  this  manner,  the  system  could  be  made  fault 
tolerant  for  faults  that  arise  as  the  result  of  trying  to  determine  an  initial  dequeue  quorum.  If  we 
include  the  events  that  are  part  of  determining  an  initial  dequeue  quorum  in  the  model,  then  we 
have  an  example  in  which  faults  may  result  in  different  internal  events  occurring  but  the  ultimate 
response  from  the  system  being  the  same.  This  is  just  the  type  of  situation  that  can  be  handled 
by  Definition  3.1  but  not  by  Definition  3.2. 


3.1.4  Graceful  Degradation 

Once  a  definition  of  fault  tolerance  has  been  decided  upon,  then  it  is  possible  to  define  various 
versions  of  graceful  degradation  by  weakening  the  definition  of  fault  tolerance  in  appropriate  ways. 
This  has  been  done  in  [3]  and,  in  a  slightly  different  way,  in  [12]. 

The  approach  taken  in  [12]  is  based  on  defining  fault  tolerance  using  constraints  on  the  system. 
If  all  of  the  constraints  are  satisfied,  then  the  system  is  fault  tolerant.  As  more  and  more  of  the 
constraints  are  not  satisfied,  the  behavior  of  the  system  is  said  to  degrade.  A  structure  can  be 
imposed  on  the  fault  tolerant  behavior  of  the  system  by  considering  the  set  of  all  possible  subsets 
of  nstraints,  i.e.  the  power  set  of  the  set  of  constraints.  This  set  forms  a  lattice  under  set 
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inclusion.  By  mapping  system  behavior  to  the  set  of  constraints  that  are  satisfied  by  the  system, 
it  is  possible  to  place  a  partial  order  on  the  different  behavior  of  the  system.  This  partial  order 
can  then  be  used  to  describe  the  manner  in  which  the  system  gracefully  degrades. 

The  approach  taken  in  [3]  is  based  on  two  possible  ways  in  which  the  definition  of  fault  tolerance 
could  be  weakened.  This  approach  extends  easily  to  our  definition  of  fault  tolerance. 

•  A  smaller  set  of  faults  might  be  tolerated.  In  the  definition,  this  involves  letting  the  set  C 
of  fault  scenarios  which  the  system  tolerates  become  progressively  smaller.  This  amounts  to 
saying  that,  as  the  system  degrades,  there  are  more  and  more  types  of  faults  from  which  the 
system  can  not  shelter  the  client. 

•  Another  form  of  graceful  degradation  might  involve  the  manner  in  which  the  system  reacts 
to  a  fault.  It  may  be  the  case  that  the  system  cannot  totally  shelter  the  client  from  the 
occurrence  of  faults  but  that  it  can  control  the  effect  that  these  faults  have  on  the  system 
behavior  in  a  well-defined  way.  In  the  definition,  for  the  same  set  C,  rather  than  requiring 
that  /3\IO  =  71 10,  it  might  only  be  required  that  (3\IO  zsj\IO  where  ^denotes  some  relation 
on  sequences  that  is  weaker  than  equality.  For  example,  the  order  of  output  events  may  be 
permuted,  or  equality  may  only  be  required  to  hold  on  a  subset  of  the  output  events.  Or  for 
a  model  involving  time,  the  response  time  to  a  request  might  fall  outside  a  specified  range. 


3.1.5  A  Comparison  with  other  Approaches 

The  main  appeal  of  Definition  3.1  as  a  definition  of  fault  tolerance  is  that  it  is  conceptually  very 
simple  and  clear.  It  is  given  at  a  high  enough  level  that  system  details  do  not  show  up  in  the 
definition.  This  allows  one  to  focus  on  exactly  what  is  meant  by  fault  tolerance  independent  of  a 
particular  system. 

The  definition  also  allows  one  to  distinguish  between  whether  the  system  is  fault  tolerant  as  opposed 
to  whether  it  is  “correct”,  i.e.  satisfies  its  specifications.  The  reason  for  this  is  that  the  definition 
is  not  based  on  any  requirements  or  specifications  for  the  system.  In  particular,  it  only  compares 
the  observable  behavior  of  the  system  in  the  presence  of  faults  with  the  behavior  in  the  absence  of 
faults.  It  says  nothing  about  whether  the  behavior  of  the  system  in  the  absence  of  faults  is  correct. 

While  this  distinction  may  be  viewed  as  an  advantage,  there  are  a  number  of  limitations  to  the 
definition  and  the  trace  model  used  to  describe  it.  Two  of  these  have  been  mentioned  earlier: 
the  fact  that  timing  specifications,  and  therefore  timing  failures,  cannot  be  represented  in  this 
model,  and  the  fact  that  stochastic  behavior  also  cannot  be  represented  in  the  model.  Both  of 
these  limitations  are  a  consequence  of  the  definition  not  depending  on  the  specification  of  system 
behavior  at  the  client’s  level.  That  is,  there  is  nothing  in  the  definition  that  talks  about  system 
failures,  only  failures  at  the  resource  level.  In  order  to  extend  the  definition  to  cover  all  cases,  it  will 
probably  be  necessary  to  define  fault  tolerance  in  terms  of  the  specifications  of  the  system  at  the 
client’s  level.  The  definition  of  fault  tolerance  can  then  be  rephrased  in  terms  of  the  specifications 
as  follows. 
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Definition:  A  server  system  S  is  fault  tolerant  with  respect  to  a  given  fault  scenario  C  if  the 
specifications  of  the  system  5  are  satisfied  for  all  system  behaviors  contained  in  C. 

More  formally, 

Definition  3.3  If  P  is  the  process  defined  by  the  traces  in  C  and  SPEC  is  the  set  of  specifications 
for  S,  then  PsatSPEC;  i.e.  the  specifications  are  satisfied  by  each  trace  in  C. 

This  approach  is  the  more  traditional  approach  to  fault  tolerance  found  in  [12]  and  others.  Graceful 
degradation  comes  from  relaxing  the  set  SPEC  of  specifications  that  must  be  satisfied.  This  could 
be  done  by  changing  the  specifications  or  by  just  requiring  that  only  some  of  them  be  satisfied.  The 
latter  approach  is  the  one  taken  by  [12]  described  earlier.  It  should  also  be  pointed  out  that  the  if 
the  trace  model  used  supports  real-time  specifications  or  specifications  of  stochastic  behavior,  then 
the  same  definition  can  still  be  used  to  include  timing  failures  and  stochastic  misbehavior. 


3.2  SERVICE  MODELS 

In  this  section  we  describe  classes  of  availability  policies  that  are  applicable  to  C2  systems.  First, 
we  describe  policies  that  do  not  require  an  explicit  notion  of  time.  We  then  provide  a  worked 
example  of  a  real-time  policy. 


3.2.1  Liveness  Policies 

A  liveness  property  of  a  system  is  a  temporal  property  that  “something  desirable  eventually  hap¬ 
pens”  as  the  system  evolves.  For  example,  successful  termination  of  a  sequential  program  is  a 
liveness  property.  We  are  concerned  here  with  modes  of  service  denial  in  which  process  interaction 
denies  a  liveness  property  to  some  process  that  was  designed  to  possess  it.  The  next  section  in¬ 
troduces  a  notational  extension  to  CSP  that  will  facilitate  the  formalization  of  these  service  denial 
modes,  the  following  section  defines  and  formalizes  deadlock,  starvation,  and  fairness,  and  the  last 
section  discusses  associated  service  policies. 


3. 2. 1.1  Notation —  We  first  introduce  a  mild  extension  of  CSP,  behaviors,  to  facilitate  the 
definition  of  liveness  properties  and  situations  that  deny  liveness.  The  extension  is  mild  because 
it  applies  CSP  theory  and  does  not  add  anything  to  the  theory.  Later  we  introduce  the  basic 
notion  of  temporal  dependence  which  lies  at  the  heart  of  the  modes  of  service  denial  discussed  here. 
In  addition  to  the  notation  defined  in  this  section,  we  also  make  use  of  the  notation  defined  in 
Section  2.2. 

The  trace  model  of  the  evolution  of  a  CSP  process  is  strongly  biased  towards  looking  backwards  in 
time  from  some  point  in  time  “now”  towards  the  beginning  of  time,  i.e.  the  start  of  the  process.  It 
is  easy  to  refer  to  a  trace  t  that  contains  an  occurrence  of  an  event  e,  as  in  “e  in  tn.  If  a  trace  t  of 
a  process  P  ends  with,  say,  the  nth  occurrence  of  event  e,  then  t  is  the  concatenation  of  the  trace  s 
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of  a  particular  evolution  of  P  with  e:  t  =  s"(e).  The  trace  s  records  a  history  of  the  behavior  of  P 
prior  to  the  nth  occurrence  of  e,  and  is  available  with  no  extra  work.  The  trace  model  makes  it  very 
easy  to  assert  safety  properties  of  a  process,  which  correspond  to  “always”  assertions  in  temporal 
logic:  A  safety  property  is  an  assertion  that  is  true  of  all  traces  of  a  process.  It  should  be  noted 
that  a  safety  property  is  an  invariant  of  a  process. 

Liveness  properties,  which  correspond  to  “sometimes”  or  “eventually”  assertions  in  temporal  logic, 
are  another  matter.  The  closest  we  can  get  to  expressing  the  idea  that  “Event  e  eventually  occurs 
in  the  lifetime  of  process  P”  with  the  basic  notational  devices  of  CSP  is  to  say  that  there  is  an 
N  such  that  all  traces  longer  than  N  contain  an  occurrence  of  e.  The  difficulty  with  this  is,  of 
course,  that  such  a  global  bound  on  the  number  of  elapsed  events  until  occurrence  of  the  event  in 
question  may  not  be  known,  and  may  not  even  exist.  In  order  to  express  liveness  properties  of  a 
CSP  process,  we  will  construct  a  new  process  attribute  called  the  process’  behaviors. 

The  construction  is  similar  to  that  in  the  theory  of  finite  automata  [14]  by  which  the  next-state 
function  S  is  extended  to  a  function  of  history  6.  Given  a  CSP  process  we  build  a  possibly  infinite  set 
of  sequences  of  events,  any  of  which  could  be  infinitely  long;  each  sequence  is  one  possible  lifetime 
behavior  of  the  process.  For  generality  we  start  with  the  theory  of  nondeterministic  processes 
laid  out  in  [13],  pp.  129  -  132  and  briefly  described  in  Section  2.2.  By  using  this  model  rather 
than  the  trace  model  used  previously  in  this  report,  it  is  possible  to  define  liveness  policies  for 
nondeterministic  processes. 

For  the  remainder  of  this  section  let  P  =  (A,  F,  D)  be  a  process.  Also,  given  a  finite  set  A  we  use 
A°°  to  denote  the  set  of  countably  infinite  sequences  of  elements  of  A  and  Aw  to  denote  the  set  of 
finite  or  countably  infinite  sequences  of  elements  of  A.  Clearly  Aw  =  A"  U  A°°.  The  connection 
between  this  model  of  processes  and  the  model  for  deterministic  processes  used  earlier  is: 

•  A  is  the  set  of  events  for  the  process. 

•  F  is  a  set  of  pairs  (s,  X)  where  s  €  A*  and  X  C  A 

•  D  is  a  set  of  elements  from  A* 

•  The  set  of  traces  of  the  process  consists  of  all  s  such  that  there  exists  some  X  with  (s,  A)  €  F. 

So,  the  model  of  process  used  in  this  section  is  an  extension  of  the  model  used  earlier  in  that  in 
addition  to  capturing  the  traces  of  the  process  it  captures  the  following  information: 

•  (s,  X)  €  F  denotes  that  after  participating  in  the  events  in  s  the  process  can  refuse  to 
participate  in  any  further  events  from  X 

•  s  €  D  denotes  that  after  participating  in  the  events  in  s  the  process  can  forevermore  choose 
'  to  participate  in  or  refuse  to  participate  in  any  event 

The  set  F  is  included  to  allow  a  distinction  to  be  made  between  a  process  that  must  participate 
in  an  event  and  a  process  that  may  choose  to  participate  in  an  event.  The  traces  only  capture  the 
events  in  which  a  process  may  participate;  they  do  not  consider  whether  the  process  has  any  choice 
to  refuse  to  participate  in  an  event.  For  example,  suppose  that  P\  is  a  server  that  is  required  to 
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process  service  requests  from  other  processes  and  P%  is  the  same  as  Pi  except  it  may  internally 
choose  to  refuse  certain  requests.  Since  both  processes  can  participate  in  the  same  event  sequences, 
they  have  the  same  traces.  The  set  F  distinguishes  between  the  two  processes  by  recording  that 
P2  may  refuse  certain  events  that  Pi  must  accept.  For  a  more  detailed  description  of  this  model 
and  the  differences  between  deterministic  and  nondeterministic  processes,  see  [13]. 

A  finite  behavior  represents  the  sequence  of  events  a  process  participates  in  until  it  stops,  due  either 
to  failure  or  to  successful  termination.  A  trace  of  P  after  which  P  has  a  non-empty  refusal  set  is  a 
behavior  that  terminates,  due  either  to  failure  or  to  success: 

Definition  3.4  t  £  A*  is  a  terminating  behavior  of  P  if  and  only  if  there  is  a  pair  ( t,B )  €  F  such 
that  B  ^  0. 

If  a  trace  of  P  has  yj  as  its  last  element  it  is  a  behavior  that  terminates  successfully.  CSP  uses  the 
symbol  uy/n  as  a  special  marker  event  to  indicate  successful  completion  of  a  terminating  sequential 
process;  see  [13],  pp.  171ff. 

An  infinite  behavior  represents  the  sequence  of  events  a  nonterminating  process  participates  in 
throughout  its  lifetime.  In  the  following,  for  any  x,y  £  Au  we  use  x  <  y  when  x  is  a  proper  initial 
segment  of  y ,  i.e. 

Definition  3.5  For  any  x,y  £  Aw,  x  <  y  if  and  only  if  there  is  a  z  £  Aw  such  that  z  ^  ()  and 
y  =  x‘z. 

When  y  =  x‘z  we  say  that  z  is  the  complement  in  y  of  x.  (Note  for  future  reference:  It  can  be 
shown  that  for  any  x,  y  £  A“,  x  <  y  only  if  x  £  A*). 

Every  finite  initial  segment  of  an  infinite  behavior  of  a  process  is  a  trace  of  the  process,  and  the 
following  event  is  one  of  the  events  the  process  may  participate  in  after  the  segment: 

Definition  3.6  h  £  A00  is  a  nonterminating  behavior  of  P  if  and  only  if  for  each  subsequence 
s  <  h  there  is  an  event  e  £  A  such  that  ( e )  £  traces(P / s)  and  s~(e)  <  h. 

Given  the  definitions  of  terminating  and  nonterminating  behaviors,  we  are  now  in  a  position  to 
define  another  attribute  of  a  process,  its  behaviors: 

Definition  3.7  Behaviors(P)  is  the  set  of  all  h  such  that  h  is  either  a  terminating  behavior  of  P 
or  a  nonterminating  behavior  of  P. 

We  note  that,  since  behaviors  are  defined  entirely  in  terms  of  the  process,  we  have  not  materially 
extended  the  mathematics  of  CSP.  However,  we  now  have  the  means  to  express  eventuality  asser¬ 
tions  about  processes.  We  note  in  passing  that  the  set  of  behaviors  of  a  CSP  process  can  be  used 
to  support  the  interpretation  of  computation-oriented  temporal  and  interval  temporal  logics  that 
base  their  semantics  on  sequences. 


41 


Of  the  mechanisms  for  combining  CSP  processes  described  in  [13],  parallel  composition  is  the  only 
one  that  allows  processes  to  interact  with  one  another.  So,  it  is  important  that  the  structural 
relationships  between  the  traces  and  behaviors  of  the  constituent  processes  and  the  traces  and 
behaviors  of  their  parallel  composition  be  well  understood.  The  basic  law  defining  the  traces  of 
the  composition  of  two  processes  in  terms  of  the  traces  of  the  components  asserts  that  the  result 
of  projecting  a  trace  of  the  composite  onto  the  alphabet  of  a  constituent  results  in  a  trace  of  the 
constituent  (see  [13],  p.  72): 

traces(P\\Q)  =  { t  |  t\aP  £  traces(P)  and  t\aQ  £  traces(Q)  and  t  £  {aP  fl  aP)}. 

It  follows  easily  from  this  law  that  the  two  constituent  traces,  when  projected  onto  the  other 
processes’  alphabet,  look  the  same: 

t\aP\aQ  =  t\(aPr\aQ) 

=  t\(aQnaP) 

=  t\aQ[aP 

by  two  applications  of  law  L6  p.  44  of  [13].  Two  traces  that  have  this  property  are  said  to  be 
parallel  compatible : 

Definition  3.8  tp  £  traces(P)  and  tQ  £  traces(Q )  are  parallel  compatible  iftp\aQ  =  tq\aP. 

We  extend  this  definition  to  behaviors  by  using  their  finite  initial  subsequences: 

Definition  3.9  Any  hp  £  behaviors(P)  and  Iiq  £  behaviors{Q )  are  parallel  compatible  if  #hp  = 
#/iq  and  for  all  tp  <  hp,tQ  <  Hq:  #tp  =  #tg=>-  tp  and  tQ  are  parallel  compatible. 

One  major  means  of  denying  service  to  a  process  is  to  prevent  its  progress.  For  a  process  to  prevent 
the  progress  of  another  process,  it  is  necessary  that  there  be  some  kind  of  mutual  interaction  in 
which  the  process  to  be  blocked  depends  on  some  behavior  on  the  part  of  the  blocker  in  order  to 
continue.  Before  we  define  the  concept  of  temporal  dependency,  however,  we  must  first  digress  a 
little  to  discuss  a  subtle  point  of  the  CSP  notation. 

The  symbols  that  comprise  the  alphabet  of  a  CSP  process  are  often  referred  to  as  events  in  the 
CSP  literature.  However,  it  is  necessary  to  understand  that  these  symbols  in  fact  are  names  for 
event  classes ,  of  which  there  may  be  any  number  of  occurrences  during  the  evolution  of  the  process 
([13],  p.  23).  Hence  a  logic  expression  like  x  =  E,  where  x  denotes  an  event  occurrence  and  E 
denotes  a  class  of  event  occurrences,  may  be  understood  as  meaning  x  £  foo. 

As  for  substitutivity  of  equals  (referential  transparency),  it  fails  in  general  when  “pivoting”  on  an 
event  name: 

x  =  E,y  =  E 

does  not  imply  x  =  y.  When  transformed,  the  premises  above  are 
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from  which  nothing  interesting  can  be  concluded. 

Suppose,  however,  that  the  expression  e  denotes  an  event  occurrence.  Then  the  deduction 
i  =  £,i  =  ehe  =  £, 

proceeds  by  substitution  of  equals  for  equals.  When  transformed,  the  resulting  rigorous  formulation 
x  €  foo,  x  =  e  b  e  6  foo 

does  in  fact  hold  by  virtue  of  substitution  of  equals  for  equals. 

There  is  a  generalization  of  this  situation  which  needs  to  be  treated.  The  question  is,  how  is  a 
predicate  in  one  or  more  event  names  to  be  handled?  In  general,  a  predication 

P(El,...En) 

can  be  replaced  by  the  formula 

n 

3ei . . .3en:  /\ (e^  €  £,)  A  P(ei,.  ,.en) 

i=i 

Given  the  above  it  is  clear  that  a  trace  is  simply  a  (0-based)  sequence  of  event  occurrences.  Thus 
an  expression  like  yo  =  foo  means  simply  j/o  €  foo. 

When  we  select  a  particular  event  occurrence,  say  the  ith  e,-,  somewhere  along  a  particular  behavior 
of  a  process,  we  see  that  all  the  events  in  the  future  of  e,-  depend  on  e,  in  the  sense  that  they  cannot 
occur  until  after  e*  does: 

Definition  3.10  The  expression  “e,  fj”  means  that  fj,  the  jih  occurrence  of  event  f,  depends 
on  e,,  the  iih  occurrence  of  event  e,  along  a  behavior  h. 

This  basic  form  of  temporal  dependence  is  an  immediate  consequence  of  the  event-driven  nature  of 
CSP  processes. 

It  follows  easily  from  the  definition  that  temporal  dependence  forms  a  strict  partial  order  relation  on 
event  occurrences  along  a  behavior.  Temporal  dependence  is  clearly  irreflexive  since  an  event  cannot 
depend  on  itself:  For  any  occurrence  i  of  event  e  e  aP  along  behavior  h,  ->ej  e,-.  Transitivity 
of  temporal  dependence  follows  immediately:  For  any  event  occurrences  e,,  fj,  and  p*  along  a 

behavior  h,  if  e,  fj  and  fj  -£►  gk  then  e,  p*.  Finally,  the  asymmetry  of  temporal  dependence 
follows  because  behaviors  are  not  circular:  For  any  event  occurrences  e,-  and  fj  along  h,  if  e,  fj 
then  ~>fj'^*  e,-. 


In  CSP  the  only  mechanism  that  allows  two  processes  to  interact  is  parallel  composition ,  in  which 
two  processes  with  intersecting  alphabets  interleave  events  not  in  the  intersection  and  lock-step 
synchronize  single  occurrences  of  events  in  the  intersection.  The  simplest  way  to  have  any  depen¬ 
dency  between  event  occurrences  e;  along  hp  in  process  P  and  fj  along  hQ  in  process  Q  is  for  either 
e,  or  fj  to  be  an  occurrence  of  an  event  in  the  intersection  of  the  two  alphabets  a P  and  aQ,  but 
not  both: 

Definition  3.11  fj  along  h.Q  in  process  Q  depends  on  e{  along  hp  in  process  P  if  either  e,  € 
aP  D  aQ  and  fj  £  aP  and  e,-  'S  fj,  or  fj  6  aP  fl  aQ  and  e,  £  aQ  and  e,  ^  fj. 

A  common  scenario  involving  three  event  occurrences  e;  along  behavior  hp  of  process  P  and  fj 
along  hQ  of  process  Q  is  for  there  to  be  some  event  occurrence  p*  in  the  intersection  of  their 

alphabets  which  acts  as  an  intermediary  in  their  parallel  composition:  e,  ^  gk  and  gk  -3>  fj. 

The  occurrences  of  common  events  in  parallel  processes  supply  the  “bridges”  by  which  the  temporal 
dependence  partial  order  of  component  processes  are  extended  into  a  temporal  dependence  partial 
order  of  the  composed  system.  The  fact  that  the  projection  of  a  parallel  process’  trace  on  the 
alphabet  of  any  component  process  yields  a  trace  of  the  component  implies  that  the  temporal 
dependencies  of  the  component  carry  over  into  the  composite  system. 


3. 2. 1.2  Modes  of  Service  Denial —  We  now  define  a  variety  of  modes  or  patterns  of  ser¬ 
vice  denial  which  arise  when  some  “malicious”  processes  deny  a  liveness  property  to  a  “victim” 
process,  and  which  are  best  described  in  terms  of  temporal  dependencies  between  the  victim  and 
the  malicious  proceses.  We  first  show  how  behaviors  can  be  used  to  express  eventuality  or  liveness 
properties  of  a  process.  We  then  discuss  three  common  modes  of  service  denial — cyclic  deadlock, 
starvation,  and  mutual  starvation.  The  three  modes  of  service  denial  are  defined  in  terms  of  tempo¬ 
ral  dependencies  among  sets  of  event  occurrences ,  and  are  defined  with  respect  to  a  single  behavior. 
Thus  it  will  always  be  possible  for  a  process  which  exhibits  service  denial  along  one  behavior  to 
evolve  without  incident  along  other  behaviors.  It  will  then  be  simple  to  negate  the  statement  of 
the  existence  of  a  particular  service  denial  pattern  along  a  particular  behavior  to  arrive  at  a  policy 
statement  of  no  service  denial  along  any  behavior. 

Any  point  in  a  particular  behavior  h  defines  a  “now”  with  respect  to  which  h  may  be  divided  into 
a  “past”  and  a  “future”: 

Definition  3.12  For  any  h  €  behaviors(P)  and  any  t  <  h,  future{t,h)  is  the  complement  in  h  of 
t. 

future(t ,  h)  is  well-defined,  although  it  may  be  the  empty  sequence  if  X  =  h.  When  h  is  a  nontermi¬ 
nating  behavior  and  t  <  h  then  future(t,  h)  is  infinite. 

Given  the  notion  of  behaviors  of  a  process,  we  can  now  assert  the  guaranteed  occurrence  of  an 
event  e  sometime  in  the  lifetime  of  process  P : 
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Vh  £  behaviors(P)  :  ( e )  in  h, 

where  “e  in  hn  means  e  is  a  contiguous  subsequence  of  h;  in  other  words,  for  some  s,t  £  Au  :  h  = 
s~e't.  Notice  that  in  this  expression  the  number  of  events  before  the  first  occurrence  of  e  may  differ 
for  each  h;  if  there  are  an  infinite  number  of  different  behaviors  then  there  may  be  no  upper  bound 
on  the  “distance”  to  the  first  occurrence  of  e. 

A  weaker  guarantee  of  event  occurrence  is  useful  for  expressing  liveness  properties  of  systems  in 
which  the  guarantee  of  eventual  occurrence  of  an  event  /  is  contingent  on  the  occurrence  of  another 
event  e:  For  all  h  £  behavior s{P),t  <  h :  if  to  =  e  then  (/)  in  future{tyh)  [18] 

Now  that  we  can  speak  of  the  future  of  a  trace  it  possible  to  express  the  idea  of  an  event  occurring 
infinitely  often.  The  proposition  that  e  happens  infinitely  often  on  all  behaviors  of  process  P  is 
captured  in  the  temporal  logic  expression  “DOe”  (see  [16],  p.  240)4  This  can  be  translated  into 
CSP  by  noting  that  DOe  means  that  Oe  holds  for  any  point  in  the  future;  in  other  words,  given 
any  point  of  time,  there  is  a  later  occurrence  of  e.  So,  the  notion  of  occurring  infinitely  often  can 
be  captured  in  CSP  as: 

Definition  3.13  e  occurs  infinitely  often  in  behavior  h  of  process  P  if  and  only  if 
h  g  A*  A  Vf  :  t  <  h  =>  (e)  in  future(t,  h ), 

From  this  definition,  the  following  theorem  is  obvious: 

Theorem  1  e  occurs  infinitely  ofen  in  behavior  h  of  process  P  if  and  only  if  the  sequence  h  contains 
infinitely  many  occurrences  of  e. 

Thus,  one  of  the  advantages  of  using  CSP  is  that  the  notion  of  an  event  occurring  infinitely  often 
has  a  much  simpler  definition  than  it  does  in  other  formalisms. 

Karp,  among  others,  uses  the  concept  of  an  event  occurring  infinitely  often  to  define  fairness  [16]. 

Definition  3.14  Let  S  be  a  process,  let  e,  f  be  members  of  aS,  and  suppose  that  an  occurrence  of 
e  is  a  necessary  but  not  sufficient  condition  for  a  subsequent  occurrence  of  f.  S  is  fair  for  f  with 
respect  to  e  if  for  all  h  £  behaviors(S),  if  e  occurs  infinitely  often  in  h  then  (/)  in  h. 

The  name  fairness  comes  from  the  field  of  operating  systems,  where  e  is  the  event  that  some  process 
becomes  ready ,  and  /  is  the  event  that  the  process  is  dispatched;  this  formalizes  the  statement,  if  a 
process  is  ready  often  enough,  it  will  eventually  be  dispatched.  Notice  that  the  negation  of  fairness 
defines  livelock:  for  some  h  £  behaviors(P),  e  occurs  infinitely  often  in  h  but  ->((/)  in  h). 

It  can  happen  that  a  pair  of  event  occurrences  has  opposite  orders  of  temporal  dependency  in  two 
different  processes: 

‘See  Section  2.4  for  a  description  of  Q  and  O. 
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Definition  3.15  Let  P  and  Q  be  CSP  processes  with  behaviors  hp  and  hQ  respectively,  and  let 
events  e,  f  £  aP  fl  aQ :  Event  occurrences  ei  and  fj  are  cyclically  dependent  if  both  e<  <3  fj  and 


When  we  form  the  parallel  composition  (P|]Q)  of  P  and  Q  above  and  consider  the  behaviors  of 
(P||Q)  that  arise  from  hp  and  hQ  (and  we  presume  that  some  exist),  we  find  that  there  exist 
sequences  tp  £  aP *,  x  £  aPm,  sp  £  aPu,  tQ  €  aQ* ,  y  £  aQ *,  and  sq  £  aQw  such  that 

hp  =  tp‘(ei)'x{fjY$p , 

hQ  =  tQ'(fjYy(eiYsQ, 

and  the  behaviors  of  (P\\Q)  that  arise  from  hp  and  hQ  are  the  members  of  the  set: 


{t  :  t\aP  =  tp  and  t\aQ  -  tg}. 

Since  no  trace  is  longer  than  (P||Q)  terminates.  Thus  the  composed  process  is  blocked 

with  P  waiting  to  participate  in  e,-  and  Q  waiting  to  participate  in  fj.  This  situation  is  called  cyclic 
deadlock.  We  must  keep  in  mind  the  fact  that  we  are  considering  those  behaviors  of  (P||Q)  that 
arise  when  P  attempts  to  progess  along  hp  and  Q  attempts  to  progress  along  /iq;  there  may  well 
be  other  evolutions  of  P  and  Q  for  which  (jP||Q)  will  evolve  forever. 

For  example,  suppose  process  P  works  by  participating  in  some  local  event  a,  and  then  sending  a 
message  on  channel  c  followed  by  awaiting  an  answer  on  channel  d: 

aP  =  {a}UacU<*d 

P  =  pXfa  —>  c!x  ->  d?y  —>  X), 

and  suppose  process  Q  is  supposed  to  work  by  participating  in  event  b  followed  by  receiving  a 
message  on  channel  c  and  sending  a  reply  on  channel  d.  However,  a  design  error  results  in  inverting 
the  order  of  the  communication  protocol  events: 

aQ  =  {6}(JacUad 

Q  =  pX.(b  -*  d\y  — *  clx  -*  X). 

When  these  two  processes  are  composed  in  parallel,  cyclic  deadlock  occurs  on  any  behavior.  The 
relevant  event  occurrences  are  c.xi  and  d.yi  (recall  that  in  CSP  the  forms  “x!y”  and  “x?j/”  are 
syntactic  sugar  for  the  communication  event  “x.y”,  designed  to  indicate  the  direction  of  information 
flow;  see  [13],  chapter  4).  In  any  behavior  hp  of  P  c.x\  d.yi,  while  in  any  behavior  /iq  of  Q 
d.y i  -vS  c.x i.  Thus  P\\Q  hangs  with  P  awaiting  c.xi  and  Q  awaiting  d.yi. 

A  cyclic  deadlock  situation  can  be  composed  of  any  number  of  event  occurrences  forming  a  depen¬ 
dency  cycle.  For  example,  if  e  £  aP  \aQ,  f  £  aQ\  aP ,  x,  y  £  aP  fl  aQ,  and  x,  ey,  ey  ~3  yk  in  a 

behavior  hp  of  P  and  y*  ft,fi  ^2  x,-  in  a  behavior  /iq  of  Q,  then  there  is  a  cyclic  dependency,  so 
P\\Q  deadlocks  with  P  waiting  to  participate  in  x,-  and  Q  waiting  to  participate  in  y*.  In  this  case 
it  is  easy  to  see  the  dependency,  since  deleting  the  two  “local”  event  occurrences  ei  and  fi  leaves 
the  basic  situation  of  two  common  events  that  must  occur  in  opposite  order  in  the  two  processes. 
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When  more  processes  are  introduced,  cyclic  dependency  may  no  longer  be  evident  between  any 
two  processes.  For  example,  consider  three  processes  P ,  Q,  and  R  with  events  e  €  otP  D  aQ, 

f  €  OiQ  n  aR,  and  g  €  aR  fl  aP:  If  e,  ^  gk  in  a  behavior  hp  of  P,  fj  e,  in  a  behavior  fig  of  Q, 

and  gk  ^3  fj  in  a  behavior  h r  of  R,  then  there  is  a  cyclic  dependency  and  P||Q||f2  will  deadlock 
with  P ,  Q,  and  R  waiting  to  participate  in  e,-,  fj,  and  gk  respectively.  However,  examination  of 
any  pair  will  only  reveal  a  single  dependency,  not  a  cycle;  thus  any  two  processes  could  proceed, 
but  the  three  processes  are  cyclically  deadlocked. 

All  the  members  of  a  set  of  processes  that  are  in  cyclic  deadlock  are  prevented  from  making  further 
progress.  Starvation,  on  the  other  hand,  is  a  form  of  service  denial  in  which  some  processes  make 
progress  themselves  while  preventing  some  “victim”  process  from  progressing.  Let  P  and  Q  be 
processes,  let  fg  be  a  crace  and  h q  be  a  behavior  of  Q  such  that  tg'e,-  <  fig  for  some  e,-  £  aQ, 
and  let  t  be  a  trace  of  P  that  is  parallel  compatible  with  tg,  i.e.  so  that  tQ\aP  =  t\aQ:  If  hp/t  is 
a  behavior  of  P/t  such  that  hp/*|aQ  =  ()  then  Q  is  starved  by  P  along  any  behavior  h  of  P\\Q 
composed  from  tp‘hP/t  and  fg.  Roughly  speaking,  P\\Q  proceeds  along  until  the  point  at  which  Q 
needs  to  participate  in  e,-,  at  which  time  P  proceeds  along  a  behavior  which  nevermore  interacts 
with  Q. 

For  example,  suppose  process  P  is  passing  a  buffer  back  and  forth  with  process  Q  and  then  at  some 
point  P  refuses  to  return  it  and  proceeds  along  its  own  private  way,  so  Q  starves  forever: 

COOPERATE,,  =  p. stuff  — ►  pass.buffer  — >  COOPERATEn~i,n  >  0, 

COOPERATEo  =  NO. FURTHER. INTERACTION, 

P  =  COOPERATE k,  and 
Q  =  pX.(q. stuff  — ►  pass.buffer  -*■  X ) 

After  k  cycles  of  cooperation  P  does  not  participate  in  pass. buffer k+1,  and  Q  waits  forever  for  par¬ 
ticipation  in  pass.bufferk+1.  In  the  definition  given  above,  fg  is  the  trace  of  Q  up  to  pass. buffer k+1 
and  t  is  the  trace  of  P  up  through  pass. buffer k+1. 

A  hybrid  situation  can  arise  when  process  P  and  process  Q  both  try  to  participate  in  events  from 
their  common  alphabet  but  the  events  are  different.  As  a  result,  the  parallel  system  is  deadlocked. 

To  see  how  this  differs  from  cyclic  dependence,  suppose  P  and  Q  are  defined  as  follows: 

P  =  e  STOP{eJ} 

Q  =  9  f  STOP{'Jt9} 


Initially  P  is  is  trying  to  participate  in  event  e.  Since  e  €  aQ,  it  cannot  do  so  until  e  is  ready 
to  participate  in  e,  too.  But  Q  is  never  ready  to  participate  in  e,  so  P  is  starved  by  Q.  After 


participating  in  g,  Q  tries  to  participate  in  /.  Because  P  never  proceeds,  it  cannot  participate 
in  /,  so  Q  becomes  starved  by  P.  Yet,  there  is  no  cyclic  dependency  since  g  /  is  the  only 


dependency. 


So,  cyclic  deadlock  is  different  from  mutual  starvation,  although  it  is  clear  that  any  instance  of 
cyclic  deadlock  is  an  instance  of  mutual  starvation. 
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Our  definition  of  mutual  starvation  is  consistent  with  the  definition  of  deadlock  given  in  [13].  This 
means  that  cyclic  deadlock  is  a  proper  subclass  of  the  type  of  deadlock  defined  in  [13]  and  that 
we  can  distinguish  between  cyclic  deadlock  and  other  types  of  deadlock  while  the  definition  in  [13] 
does  not  allow  such  a  distinction  to  be  made. 

Starvation  is  not  a  subclass  of  mutual  starvation  since  one  of  the  processes  continues  execution  in 
the  case  of  starvation  while  both  processes  are  blocked  in  the  case  of  mutual  starvation.  It  is  also 
clear  that  mutual  starvation  is  not  a  subclass  of  starvation;  consequently,  the  concepts  are  mutually 
exclusive.  This  means  that  starvation  is  not  addressed  by  the  definition  of  deadlock  given  in  [13]. 
Although  the  system  can  still  perform  useful  processing  when  starvation  occurs,  there  are  instances 
in  which  it  is  undesirable  for  certain  processes  to  be  starved.  Thus,  it  is  important  to  have  a  formal 
definition  of  starvation  that  allows  occurrences  of  it  to  be  identified. 


3. 2. 1.3  Service  Denial  Policies —  The  notions  of  dependency,  deadlock,  and  starvation  have 
been  defined  with  respect  to  particular  occurrences  of  events.  To  state  predicates  concerning 
dependency  relations  we  need  to  extend  these  definitions  to  repeatable  or  universal  properties 
expressed  in  terms  of  events  (strictly,  event  classes,  as  opposed  to  event  occurrences).  We  first 
extend  the  idea  of  temporal  dependency  to  events  in  a  particular  behavior.  In  the  following,  let 
P  =  {A,  F,  D)  be  a  process,  h  be  a  behavior  of  P,  and  e  and  /  be  events  in  A. 

We  say  that  event  /  depends  on  event  e  in  a  behavior  h  if  each  new  occurrence  /,•  of  /  is  preceded 
by  a  new  occurrence  of  e: 

Definition  3.16  /  (temporally)  depends  on  e  in  h  if  and  only  if 
Vt  <  h:  t  G  A*  tif  <  tie 

We  note  that  this  definition  allows  there  to  be  arbitrarily  many  occurrences  of  the  event  depended 
on  before  the  next  occurrence  of  the  dependent  event.  It  is  possible  to  restrict  the  degree  of 
“buffering  ahead”  that  is  possible,  but  we  will  not  explore  this  further. 

This  behavior-specific  relationship  can  be  strengthened  to  dependency  over  all  behaviors: 
Definition  3.17  /  (temporally)  depends  on  e  in  P  if  and  only  if 
V/i  6  behaviors(P),  Vt  <  h  :t  G  A*  =>■  t[f  <  t[e 
We  have  the  result 

Theorem  2  If  f  depends  on  e  in  h  then  Vt  >  0  :  e;  -£►  /,• 
and  similarly  over  all  behaviors. 

As  discussed  in  [13],  pp.  161-170,  a  convenient  way  to  model  the  sharing  of  a  resource  by  client 
processes  is  by  interleaving  the  client  processes,  composing  the  interleaved  clients  in  parallel  with 
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the  resource,  and  hiding  the  alphabet  of  the  resource.  The  result  is  a  compound  process  in  which 
the  resource  access  is  hidden  from  the  externally  visible  event  stream.  The  use  of  interleaving 
allows  the  protocol  for  accessing  the  resource  to  be  made  explicit,  so  that  properties  of  coherent 
resource  access  may  be  formulated  and  (hopefully)  proven  of  a  system  model.  If  it  is  desired  to  have 
the  clients  access  a  set  of  resources,  then  all  the  resources  are  composed  in  parallel  (usually  with 
disjoint  alphabets),  and  the  resulting  composite  replaces  “the  resource”  in  the  description  above. 

Since  the  interleaved  clients  cannot  interact  directly  with  one  another,  the  only  way  to  obtain  any 
sort  of  temporal  dependence  among  the  clients  is  for  an  event  occurrence  dt-  along  hp  in  client 
process  P  to  depend  on  an  event  occurrence  gi  along  Hq  in  client  process  Q  by  having  intermediary 

event  occurrences  ej  and  fk  in  the  resource  process  R  such  that  d,-  ej,  ej  ^2  fk,  and  /*  g\. 

One  way  to  obtain  this  relationship  is  described  in 

Theorem  3  Let  P  and  Q  be  processes  with  aP  =  aQ  —  A,  R  be  a  resource  process  with  aR  C  A, 
d  and  g  be  events  €  A\aR,  and  e  and  f  be  events  £  otR. 

If  e  depends  on  d  in  P,  f  depends  on  e  in  R,  and  g  depends  on  f  in  Q,  then  g  depends  on  d  in 

R//(P\\\Q) 

Since  a  common  source  of  deadlock  in  real-systems  is  the  result  of  shared  resources,  it  is  important 
to  have  a  theorem  such  as  this  that  allows  the  detection  of  potential  deadlocks  through  the  sharing 
of  resources. 

We  can  identify  several  levels  of  “sensitivity”  of  liveness  contingent  on  another  event  (see  3. 2. 1.2), 
as  discussed  in  [8].  The  strongest  form  obtains  when  an  event  /  is  guaranteed  to  occur  merely  on 
the  single  occurrence  of  event  e.  When  this  happens,  we  have  that  the  future  of  the  itk  occurrence 
of  e  contains  the  ith  occurrence  of  /: 

Vh,t,i  :  t  <  h  f\t[e  =  i  At0  =  e  =$■  future(t,  h)  If  >lAt|/  =  t-l. 

This  strong  guarantee  might  be  appropriate  for  responsiveness  to  internally  generated  events,  where 
some  control  can  be  designed  in.  However,  it  is  likely  to  be  too  strong  for  externally  generated 
events  which  may  arrive  at  awkward  times  when  immediate  response  is  impossible. 

A  somewhat  weaker  form  of  the  liveness  guarantee  merely  guarantees  that  if  the  triggering  event 
occurs  infinitely  often  the  response  event  will  eventually  occur.  This  may  best  be  understood 
negatively  as  saying  that  there  is  no  behavior  along  which  the  triggering  event  occurs  infinitely 
often  while  the  desired  event  never  occurs: 

V/i,  t,  v  :  v  =  future(t,  h )  =>  ((Vs  :  s  <  v  =>  e  in  future(s,  v))  =>  /  in  v) 

To  understand  what  this  means,  suppose  t  is  a  trace  of  the  system  and  let  v  be  an  arbitrary  sequence 
so  that  t‘v  is  a  behavior  of  the  system.  Then,  the  requirement  is  that  whenever  e  occurs  infinitely 
often  in  v,  then  /  occurs  in  v.  So,  no  matter  what  point  is  reach  in  the  processing,  it  is  always  the 
case  that  there  cannot  subsequently  be  the  occurrence  of  an  infinite  number  of  e’s  without  there 
being  at  least  one  occurrence  of  /. 
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This  guarantee  of  responsiveness  would  be  appropriate  for  example  for  a  process  waiting  on  a 
semaphore. 

Along  with  a  statement  of  liveness  it  may  be  desirable  to  require  that  there  be  no  spurious  responses, 
i.e.  responses  that  were  not  “caused”  by  the  triggering  event  (we  place  “cause”  in  quotes  because 
there  is  no  full-blown  concept  of  causality  here,  and  we  do  not  define  one).  This  restriction  is 
well  expressed  by  the  extension  of  temporal  dependen  ;•  to  event  classes  that  was  introduced  at 
the  beginning  of  section  3. 2. 1.3.  The  statement  that  /  temporally  depends  on  e  in  behavior  A 
captures  the  idea  that  the  iih  occurrence  of  /  is  guaranteed  to  be  preceded  by  the  i,A  occurrence 
of  e  in  A. 

The  most  basic  service  assurance  policy  with  respect  to  cyclic  deadlock  would  be  the  assertion  that 
no  such  pattern  of  event  occurrences  exists  on  any  behavior  of  the  system: 

Cyclic  Deadlock  Policy 

VAp,  Aq,  e,  f,  i,j  :  ex  ^  fj  =>  ex  fj. 

While  effective,  this  may  not  be  feasible.  In  particular,  it  does  not  take  into  account  that  the 
behavior  of  user  processes  may  not  be  controllable.  To  address  this,  we  must  weaken  the  policy 
so  that  rather  than  requiring  that  there  be  no  deadlock,  it  requires  that  only  certain  processes  be 
deadlocked. 

Conditional  Cyclic  Deadlock  Policy 

VAp,  Aq,  e,  /,  i,j  :  e,  ^5  fj  e,  -3  fj. 
unless  P  and  Q  are  permitted  to  be  deadlocked. 

This  assumes  that  a  relation  has  been  defined  on  the  processes  that  indicates  which  processes  may 
be  deadlocked.  For  example,  it  might  be  reasonable  to  require  that  user  processes  and  system 
services  can  never  become  deadlocked.  Then,  the  above  policy  would  prevent  system  services  from 
becoming  deadlocked  with  user  processes  while  ignoring  the  possibility  of  user  processes  becoming 
deadlocked  with  each  other. 

Basic  service  assurance  policies  for  starvation  and  mutual  starvation  can  be  derived  in  a  similar 
fashion  to  that  for  cyclic  deadlock. 

Starvation  Policy 

VAp,  Aq,  e,  i,tp  :  tp  ti  <  Ap  =>  3 tQ  :  tcj'e,  <  Aq. 

Mutual  Starvation  Policy 
VAp,  Aq  :  Ap|aQ  =  Aq|oP 
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Once  again  these  policies  can  be  condi tionJjzed  to  be  less  stringent. 

Conditional  Starvation  Policy 

V/ip,h<5,e,i,tp  :  tp'e,-  <  hp  =!>•  3tg  :  tQ*e,-  <  hg. 

unless  P  is  permitted  to  starve  Q. 

Conditional  Mutual  Starvation  Policy 

Vhp,h,Q  :  hp\aQ  =  hg|aP 

unless  P  and  Q  are  permitted  to  starve  each  other. 

As  with  the  cyclic  deadlock  policy,  a  relation  must  be  defined  specifying  when  a  process  can  starve 
another  process.  One  possibility  would  be  to  allow  system  services  from  starving  user  processes 
while  prohibiting  user  processes  from  starving  system  services. 

Although  the  discussion  in  this  section  is  given  in  terms  of  the  model  for  nondeterministic  processes 
in  CSP,  the  policies  developed  are  only  applicable  for  deterministic  processes  in  CSP  since  they 
make  little  use  if  any  of  process  attributes  other  than  traces.  Further  research  needs  to  be  done 
to  determine  the  degree  to  which  real-systems  are  nondeterministic  in  the  CSP  sense.  If  it  is 
determined  that  it  is  common  for  real-systems  to  be  nondeterministic  in  the  CSP  sense,  that  the 
definitions  in  this  section  must  be  generalized  to  address  nondeterministic  processes.  This  will 
require  adequately  addressing  the  failures  ( F )  and  divergences  (D). 

If  D  is  nonempty,  then  it  is  possible  for  the  process  to  enter  states  from  which  it  is  impossible 
to  know  what  processing  will  subsequently  be  done.  Essentially,  there  is  a  trace  s  such  that  the 
behavior  of  the  process  after  s  is  undefined5.  Clearly  it  is  not  possible  to  show  that  deadlock 
does  not  occur  after  s  since  there  is  no  information  available  concerning  the  behavior  after  s. 
Consequently,  D  can  be  addressed  by  requiring  that  it  be  empty. 

Now,  consider  F.  Suppose  P  is  a  process  such  that: 

•  (sp,X)  €  Fp 

•  eel 

•  (sp‘(e),{})€FP« 

•  (vm  {})€*> 

and  suppose  P  is  composed  with  a  process  Q  such  that: 

•  (*«>{})€  fQ 

5 Although  technically  the  behavior  is  defined,  it  is  defined  to  be  unconstrained.  Thus,  no  useful  assertions  can  be 
made  about  the  future  behavior 

‘Note  that  (<,  {})  €  F  if  and  only  if  <  is  a  trace. 
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•  sqIoP  =  sp\aQ 

•  (sQ*(e),{})  €  Fq 

After  P  and  Q  participate  in  sp  and  sq ,  respectively,  Q  can  only  particpate  in  e  if  P  is  also  willing 
to  participate  in  e.  Since  e  6  I,  where  ( sp,X )  €  Fp,  P  can  choose  to  refuse  to  participate  in 
e  even  though  Q  is  attempting  to  participate  in  e.  For  example,  sp‘{f )  is  a  trace  for  P,  so  P 
could  participate  in  /.  This  would  result  in  Q  being  blocked.  If  P  depends  on  interaction  with  Q 
subsequent  to  sp,  then  mutual  starvation  would  occur.  This  is  addressed  by  our  definition  since 
sp‘(f )  is  not  parallel  compatible  with  SQ*(e).  If  P  does  not  require  further  interaction  with  Q , 
then  only  Q  is  starved.  This  is  addressed  by  our  definition  since  P  can  progress  after  participating 
in  /  even  though  Q  is  blocked. 

Now,  suppose  P  and  Q  are  as  before  except  we  assume  e  is  not  in  any  X  for  which  (s,  X)  €  Fp. 
Then,  P  cannot  refuse  e  when  Q  attempts  to  participate  in  e.  So,  even  though  our  definitions 
identify  the  potential  mutual  starvation  or  starvation  described  above,  the  mutual  starvation  and 
starvation  are  avoided  since  P  is  “intelligent”  enough  to  avoid  behaviors  that  are  not  consistent 
with  Q.  Because  our  definitions  do  not  make  full  use  of  the  set  F,  they  do  not  distinguish  between 
this  case  in  which  there  is  no  mutual  starvation  or  starvation  and  the  previous  case  in  which  there 
either  is  mutual  starvation  or  starvation.  To  distinguish  between  these  cases,  define: 

Definition  3.18  A  behavior  hp  of  P  is  inconsistent  with  a  behavior  Iiq  of  Q  if  and  only  if: 

Given  tp,tQ,e,f  such  that: 

•  tp~{e)  <  hp 

•  tQ~if)  <  hQ 

•  tp  is  parallel  compatible  with  tq  (i.e.  tp\aQ  =  tq\aP) 

•  e,f  €  ( aP )  D  (aQ) 

•  e  ^  / 

then  either: 

•  (*/>*</)>{})  €  Fp  and  ( tp,f )  FP,  or 

•  (*Q'(eM})  6  Fq  and  (fp,e)  £  Fq 


In  other  words,  there  is  some  point  at  which  hp  and  hq  are  in  disagreement,  even  though  the 
processes  are  prohibited  from  disagreeing  at  that  point. 

The  parallel  composition  of  processes  is  defined  so  that  inconsistent  behaviors  are  prevented  from 
occurring  simultaneously.  Thus,  there  is  no  concern  in  the  case  in  which  P  and  Q  experience 
starvation  or  mutual  starvation  through  hp  and  hq  with  respect  to  our  earlier  definitions  unless 
hp  and  /iq  are  consistent. 
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Based  on  the  above  discussion,  it  seems  reasonable  to  change  our  earlier  definitions  so  that  they 
require  the  pairs  of  behaviors  of  P  and  Q  considered  to  be  consistent.  Further  research  is  required 
to  determine  if  this  is  adequate  to  address  systems  that  are  nondeterministic  in  the  CSP  sense. 


3.2.2  Example  Real-Time  Policy 

In  this  section  we  provide  a  worked  example  of  a  real-time  policy.  Our  example  is  based  on  the 
elevator  example  provided  in  Algorithms  for  Fault  Tolerant  Distributed  Systems  [17].  In  [17],  the 
elevator  and  its  real-time  policy  are  specified  in  a  flavor  of  interval  temporal  logic  (ITL). 


3. 2. 2.1  Elevator  Model —  In  this  section,  the  elevator  system  is  specified  in  terms  of  time- 
dependent  state  predicates  and  ITL.  The  ITL  specifications  in  this  section  are  copied  from  [17]. 
There  are  some  errors  in  the  model  in  [17]  that  have  been  corrected  here  and  show  up  as  deviations 
between  the  ITL  specification  and  the  other  specifications.  We  discuss  these  deviations  as  they 
are  encountered.  The  next  section  defines  state  predicates  that  we  use  in  the  specification  of  the 
elevator.  The  subsequent  sections  provide  the  model,  policy,  and  analysis  for  the  elevator. 

We  are  not  developing  an  RTL  model  because  it  is  very  difficult  to  phrase  some  of  the  assertions 
in  RTL.  For  example,  consider  the  assertion  that  the  elevator  is  never  on  more  than  one  floor  at  a 
time.  In  RTL,  we  can  represent  this  by  defining  state  predicates  that  test  whether  the  elevator  is 
on  each  floor.  Then,  we  can  say  that  the  elevator  is  on  floor  t  at  a  given  time  if  it  reached  floor  *  at 
an  earlier  time  but  did  not  leave  floor  i  until  a  later  time.  Now  consider  the  following  assertions: 

•  The  elevator  is  on  floor  i  at  a  time  if  the  elevator  previously  reached  the  floor  for  the  jth  time 
and  subsequently  left  the  floor  for  the  jth  time. 

•  The  elevator  is  on  floor  i  at  a  time  if  the  elevator  previously  reached  the  floor  for  the  jth  time 
and  subsequently  left  the  floor  for  the  j  -f  1st  time. 

Until  we  know  whether  the  elevator  was  initially  on  floor  i,  there  is  no  way  to  determine  which 
assertion  is  correct.  We  do  not  feel  it  is  worthwhile  adding  implementation  detail  to  the  model 
simply  to  provide  an  RTL  example  of  the  elevator. 

But,  we  do  feel  that  the  notion  of  state  predicates  in  RTL  is  worthwhile.  So,  we  develop  a  state 
predicate  model.  The  state  predicate  model  is  a  very  primitive  model  in  which  we  can  use  state 
predicates  to  determine  the  state  of  the  system  at  any  given  time.  We  use  5(f)  to  test  the  value  of 
state  predicate  5  at  time  t- 

We  use  the  following  primitive  state  predicates: 

•  above.floor{i,  t)  —  indicates  whether  the  elevator  is  above  floor  i  and  below  floor  i  -(- 1  at  time 

t, 

•  door$_closed(i,t)  —  indicates  whether  the  doors  on  floor  i  are  closed  at  time  t, 
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•  doors.closing(i,  t)  —  indicates  whether  the  doors  on  floor  :  are  closing  but  not  yet  closed  at 
time  t, 

•  doors-obstructed(i,t )  —  indicates  whether  the  doors  on  floor  i  are  obstructed  at  time  t, 

•  doors.open(i,t)  —  indicates  whether  the  doors  on  floor  i  are  open  at  time  *, 

•  doors -opening(i,  t )  —  indicates  whether  the  doors  on  floor  i  are  opening  but  not  yet  open  at 
time  *, 

•  down-requested(i,t)  —  indicates  whether  the  down  button  on  floor  t  is  pressed  at  time  f, 

•  floor -requested(i,  t)  —  indicates  whether  the  button  corresponding  to  floor  t  in  the  elevator  is 
pressed  at  time  t, 

•  goingjup(t )  —  indicates  whether  the  elevator  is  either  travelling  upwards  or  intending  to  travel 
upwards  at  time  t, 

•  lift.closedft)  —  indicates  whether  the  lift  doors  are  closed  at  time  t, 

•  lift-closing(i)  —  indicates  whether  the  lift  doors  are  closing  but  not  yet  closed  at  time  i, 

•  lift-0 bstructed(t)  — -  indicates  whether  the  lift  doors  are  obstructed  at  time  t, 

•  lift-open(t)  —  indicates  whether  the  lift  doors  are  open  at  time  t, 

•  lift-opening(t )  —  indicates  whether  the  lift  doors  are  opening  but  not  yet  open  at  time  t, 

•  on-floor(i,t )  —  indicates  whether  the  elevator  is  on  floor  t  at  time  f, 

•  up-requested(i,  t)  —  indicates  whether  the  up  button  on  floor  i  is  pressed  at  time  t, 

We  also  use  the  following  derived  state  predicates7: 

•  downJight(i,l)  —  indicates  whether  the  down  button  on  floor  t  has  been  pressed  without  the 
elevator  subsequently  servicing  floor  i;  more  formally,  this  predicate  evaluates  to  true  if  and 
only  if: 

3ti  such  that  : 

doum-requested(i,ti) 
and  doors -closed(i,  ti) 
and  Vt2  €  (ti,/]  :  ->servicmp(t,t2) 

•  floor  Jig  ht(i,t)  —  indicates  whether  the  button  corresponding  to  floor  i  in  the  elevator  has 
been  pressed  without  the  elevator  subsequently  servicing  floor  t;  more  formally,  this  predicate 
evaluates  to  true  if  and  only  if: 

3ti  such  that  : 

floor  .requested^,  <i) 

7The  derived  state  predicates  are  defined  in  terms  of  the  primitive  state  predicates. 
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and  doors-closed(i,  ti) 

and  Vf2  €  :  -'servicing,  *2) 

•  request Jight(i,  t)  —  indicates  whether  a  request  is  pending  for  floor  t  at  time  t;  more  formally, 
this  predicate  evaluates  to  true  if  and  only  if: 

upJight(i,  t ) 
or  downJight(i,  t) 
or  floor Jight(i,t) 

•  reverse(t )  —  indicates  that  the  elevator  has  changed  the  direction  it  intends  to  travel  at  time 
t;  more  formally,  this  predicate  evaluates  to  true  if  and  only  if: 

3t>,  ti  such  that  ti  <  t  : 

V<2  €  (*i,t)  :  ( going jup{ti )  ^  going.up(t )) 

•  servicing{i,  t)  —  indicates  whether  the  elevator  is  servicing  floor  i  at  time  i;  more  formally, 
this  predicate  evaluates  to  true  if  and  only  if: 

on-floor{i ,  t) 
and  lift-open(t) 
and  doors.open(i,t) 

•  upjight(i,t )  —  indicates  whether  the  up  button  on  floor  t  has  been  pressed  without  the 
elevator  subsequently  servicing  floor  *;  more  formally,  this  predicate  evaluates  to  true  if  and 
only  if: 

3*i  such  that  : 

up.requested(i,tx ) 
and  doors~closed(i,ti) 
and  V*2  €  (*i,*]  :  ~'Servicing(i,t2 ) 

The  following  constraints  on  the  state  predicates  describe  the  desired  operation  of  the  elevator.  For 
ease  of  comparison,  we  have  included  both  the  ITL  specification8  from  [17]  and  our  state  predicate 
versions  of  each  constraint.  Whenever  the  ITL  version  and  state  predicate  version  of  a  constraint 
are  not  in  agreement,  we  discuss  the  reason  for  the  difference.  Note  that  since  =>  is  an  interval 
operator  in  ITL,  D  is  used  to  denote  logical  implication  in  ITL.  To  avoid  confusion,  we  use  implies 
to  denote  logical  implication  in  the  state  predicate  specifications. 

•  Constraints  on  on-floor. 

*See  Section  2.5  for  a  description  of  ITL 
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a.  The  elevator  can  never  go  below  floor  0  or  above  floor  MAXjioor. 

-  ITL:  ->  at  floor  (-1)  A  -1  atfloor  (n  +  1) 

In  addition  to  requiring  that  the  elevator  is  never  at  floor  -1  or  floor  n  +  1),  it  is 
necessary  to  require  that  the  elevator  not  be  at  other  invalid  floors.  Thus,  the  model 
we  have  developed  here  has  a  stronger  assertion. 

-  State  Predicates 
Vi,  t : 

i  <  0 

or  i  ^  Af  .A  X j loov 
implies 

~<on.floor{i,t) 

b.  The  elevator  cannot  be  on  more  than  one  floor  at  the  same  time. 

-  ITL 

b  ^  aAatfloor  (a)  D  -iatfloor(b) 

-  State  Predicates 

Vi,j,t  : 

on.floor{i ,  t ) 
and  i  j 
implies 

~>on.floor{j,  t) 

•  Constraints  on  above.floor. 

The  constraints  relevant  to  above.floor  have  no  analogues  in  the  ITL  specification.  In  the  ITL 
specification,  it  is  assumed  that  an  elevator  is  always  on  some  floor.  When  the  elevator  moves 
from  one  floor  to  another,  it  does  so  instantaneously.  This  makes  it  impossible  to  distinguish 
between  the  case  in  which  a  button  is  pressed  while  the  elevator  is  stationary  at  a  floor  and 
the  case  in  which  a  button  is  pressed  while  the  elevator  is  in  motion  leaving  a  floor.  As  a 
side-effect  of  this,  it  appears  that  if  the  elevator  is  at  a  floor  with  it  doors  closed,  a  button 
is  pressed  at  that  floor,  and  no  other  buttons  are  ever  pressed,  that  the  elevator  can  simply 
sit  at  the  floor  with  its  doors  closed  forever.  Since  we  do  not  want  our  elevator  to  behave  like 
this,  it  is  necessary  to  allow  for  the  possibility  that  the  elevator  is  sometimes  between  floors 
rather  than  actually  on  a  floor. 

a.  The  elevator  cannot  be  between  one  pair  of  consecutive  floors  at  the  same  time  as  it  is 

between  another  pair  of  consecutive  floors. 

Vi,j,t : 

above. floor[i,  t ) 
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and  i  /  j 
implies 

-iabove.floor(jtt) 

b.  The  elevator  can  never  go  below  floor  0  or  above  floor  M AX Floor- 
Vi,t : 

i  <  0 

or  i  >  MAX  floor 
implies 

->above.floor(i,  t) 

•  Constraints  on  up-requested : 

a.  There  is  no  up  button  on  floor  MAXji00r  or  nonexistent  floors. 

-  ITL 

-i  light  (n,up) 

In  addition  to  requiring  that  an  up  request  is  never  made  at  the  top  floor,  it  is  necessary 
to  require  that  an  up  request  is  never  made  for  invalid  floors.  Thus,  the  model  we 
have  developed  here  has  a  stronger  assertion. 

-  State  Predicate 
Vi,  t  : 

i  <  0 

or  i  >  MAX  floor 
implies 

-i <up-requested(i ,  t) 

•  Constraints  on  down-requested: 

a.  There  is  no  down  button  on  floor  0  or  nonexistent  floors. 

-  ITL 

-i  light  ( 0,down ) 

In  addition  to  requiring  that  a  down  request  is  never  made  at  the  bottom  floor,  it  is 
necessary  to  require  that  a  down  request  is  never  made  for  invalid  floors.  Thus,  the 
model  we  have  developed  here  has  a  stronger  assertion. 

-  State  Predicate 
Vi,  t : 

i  <  0 
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or  i  >  MAXfioor 
implies 

-idowri-requested(  i,  t ) 

•  Constraints  on  floor  .requested: 

None  of  the  constraints  from  the  ITL  specification  are  relevant,  so  only  the  state  predicate 
versions  are  listed. 

a.  There  is  only  a  button  corresponding  to  floors  0  through  MAXfioor  inclusive  in  the 
elevator. 

Vi,t : 

t  <  0 

or  »'  >  MAXfi00T 
implies 

-> floor. requested(i,  t ) 

•  Constraints  on  elevator  movement: 

a.  The  elevator  can  move  only  to  adjacent  floors. 

-  ITL 

fatfloor(a)  =>•  before  (atfloor(a+lJ  V  atfloor(a-l))]  □  atfloor(a) 

Actually,  this  says  that  if  the  elevator  is  at  floor  a  and  is  later  at  either  floor  a  —  1  or 
floor  a  +  1,  then  during  the  time  between  when  it  is  on  floor  a  and  later  reaches  an 

adjacent  floor,  it  is  always  on  floor  a.  So,  if  the  elevator  is  at  floor  0,  this  assertion 

does  not  prevent  it  from  jumping  to  floor  2  as  long  as  the  elevator  never  visits  floor 
1.  Although  the  specification  we  use  in  our  state  predicate  model  is  more  complex,  it 
accurately  captures  the  assertion. 

-  State  Predicate 
Vt,j,ti,t2  such  that  ti  <  t2  : 

on.floor(i,ti ) 
and  on.floor(j,  tf) 
and  Vfc,t  €  (hfli)  '•  ~l on.floor(k,t ) 
implies 

j  =  t  +  1  and  Vf  €  :  above_floor(i,t) 

or  j  +  1  =  i  and  Vt  G  (*i,<2) :  above_floor(j,t) 
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b.  If  the  elevator  is  at  a  floor,  a  request  is  pending  for  some  other  floor,  and  the  doors  are 
closed,  then  the  elevator  begins  movement  to  an  adjacent  floor. 

-  ITL 

b  ^  a  D  [(closed(a)  A  light(b,  dir)  )  =>  (closed  (a)  A  light(b,dir))  +  movement-time] 

□  inservice  D  (*  atfloor(a-tl)  V*  atfloor(a-l))9 

Note  that  this  ITL  assertion  also  addresses  the  next  requirement.  Also,  note  that  the 
ITL  specification  allows  for  the  possibility  that  the  elevator  might  go  out  of  service  at 
any  time.  We  have  not  addressed  this  possibility  in  our  model.  This  is  not  a  serious 
deficiency  in  our  model.  It  simplifies  the  model  and  really  subtracts  nothing  since 
the  policy  developed  for  the  elevator  is  only  relevant  to  operational  elevators.  If  we 
instead  were  interested  in  a  policy  such  as: 

When  the  elevator  becomes  operational  after  being  out  of  service,  it  always  returns 
to  floor  0. 

then  we  clearly  would  need  to  model  the  possibility  that  the  elevator  is  out  of  service. 
In  any  case,  it  would  be  straightforward  to  add  the  out  of  service  possibility  to  our 
model. 

-  State  Predicate 

3  £  i 

and  request Jight(j ,  t2) 

and  Vf  €  (f  1 ,  t2)  :  on-floor(i,  t ) 

and  doors -closed(i,  t2) 

implies 

Either: 

( going-up(t2 )  and  above -floor{i,t2)) 
or  (-> going -up(t2)  and  above.floor(i  -  1,  t2)) 

c.  Anytime  the  elevator  is  in  motion,  it  will  reach  the  next  floor  within  time  movement-time 
unless  it  reverses. 

-  ITL 

6  ^  a  D  [(closed(a)  A  light(b,  dir)  )  =>  (closed  (a)  A  light(b,dir ))  +  movement-time ] 

□  inservice  D  (*  atfloor(a+l)  V*  atfloor(a-l)) 

Note  that  this  ITL  assertion  also  addresses  the  previous  requirement. 

9 [1 7]  does  not  define  the  meaning  of  *e  when  e  is  an  event  rather  than  an  interval.  We  suspect  *e  is  meant  to  be 
interpretted  as  Oe. 
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-  State  Predicate 
Vf,i  : 

above .floor(i,  t) 
and  either: 

( goingjup(t )  and  (V*i  €  (*,*  +  movement  Jime]  :  -<on.floor(i  +  l,*i)) 
or  (-1 going.up(t )  and  (V*2  €  (t,t  +  movement  Jime]  :  ->on-floor(i,t2)) 

implies 

3*3  €(*,*  +  movementJime]  :  reverse(t 3) 

d.  The  elevator  must  always  be  on  a  floor  or  between  two  consecutive  floors. 

Since  the  ITL  specification  does  not  allow  for  the  elevator  to  be  between  floors,  the 
analogous  requirement  in  the  ITL  specification  would  be  that  the  elevator  is  always  at 
some  floor.  Interestingly  enough,  there  is  no  requirement  in  the  ITL  specification  that 
the  elevator  always  be  at  some  floor.  It  appears  that  the  elevator’s  service  policy  can  be 
violated  if  the  elevator  is  initially  not  at  any  floor. 

Vt  : 

3i  :  on.floor{i,i) 
or  3 j  :  above.floor(j,t ) 

•  Constraints  on  door  movement: 

a.  Any  time  the  doors  are  open  and  a  request  is  pending  for  some  other  floor,  the  doors  will 
begin  to  close  within  time  max.openJime  unless  they  are  obstructed. 

-  ITL 

b  ^  a  D  [(open(a)  A  light(b,dir))  =>  open(a)  A  light(b,dir))  +  max.openJime] 
a  (inservice  /\~i  obstructed(a))  D  *  closing  (a) 

-  State  Predicate 
V*,t,  j : 

doors-open(i,t ) 
and  i  ^  j 

and  request Jight(j ,  t) 

and  Vifj  €(*,*  +  max.openJime]  :  ->doors-closing{i,t) 
implies 

3t2  €  (M  +  max.openJime ]  :  doors.obstructed(i,t ) 
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b.  The  states  opening,  open,  closed,  and  closing  are  complete  and  mutually  exclusive. 

-  ITL 

(opening(a)  V  open(a)  V  closing(a)  V  closed(a))  A  {{opening (a)  V  open(a))  O 
(closing (a)  V  closed(a)))  A  {{opening(a)  V  closing(a))  O 
-i  (open(a)  V  closed(a))) 

-  State  Predicate 

V*,t  : 

Either: 

doors -opening(i,  t) 
or  doors-open{i,  t) 
or  doors-closed{i,t) 
or  doors.closing{i,t ) 

and  doors-opening{i,  t)  implies 

-i{doors-open{i,t)  or  doors.closed{i,t)  or  doors-closingfi,  t)) 

and  doors-open{i,t)  implies 

- <{doors~opening{i,t )  or  doors.closed{i,t)  or  doors-closing{i,t)) 
and  doors-closed{i,t)  implies 

-i {doors-open{i,t)  or  doors.opening{i,t )  or  doors.closing{i,t )) 

and  doors -closing(i,  t)  implies 

-\{doors..open{i,  t)  or  doors~closed{i,t )  or  doors-opening(i,i )) 

c.  Between  the  time  a  set  of  doors  is  open  and  it  begins  closing,  the  doors  remain  open. 

-  ITL 

open(a)  =>  before  closing  (a)]  Oopen(a) 

-  State  Predicate 

doors.open(i,ti) 
and  doors-closing{i,  f2) 
and  V*3  €  (*i,*2)  :  ~'doors.closing{i,t2 ) 

implies 

V*4  6  (*i,i2)  :  doors.open{i,t4 ) 

d.  Between  the  time  a  set  of  doors  is  closed  and  it  begins  opening,  the  doors  remain  closed. 

-  ITL 

fclosed(a)  =$>  before  opening  (a)]  □  closed(a) 
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-  State  Predicate 

doors.closed(  i,t\) 

and  door$_opening(i,t2 ) 

and  Vt3  €  (t  1,^2)  :  -^doors.opening(i,  t2) 
implies 

Vt4  6  (h,h)  :  doors. closed(i, t4) 

e.  When  the  elevator  is  not  in  motion,  the  doors  for  the  floor  that  it  is  on  are  in  the  same 
state  as  the  elevator  doors  while  all  other  doors  are  closed. 

-  ITL 

opening  (lift)  O  3a  :  0  <  a  <  nA  opening(a) 

0  <  a  <  n  D  opening(a)  =>  closed(a)]  Q  atfloor(a)  A  (opening (lift)  opening(a))  A 
(open (lift)  O  open(a))  A  (closing (lift)  closing(a))  A  (closed(lift)  O  closed(a)) 

These  ITL  assertions  have  the  same  intent  as  our  assertion,  but  are  different  for  two 
reasons.  First,  the  ITL  specification  has  no  concept  of  movement.  Second,  an  assertion 
of  the  form  [I  =>  J]P  is  defined  to  be  vacuously  true  whenever  there  is  no  J  interval 
following  an  I  interval.  Thus,  if  the  doors  begin  opening  and  never  subsequently 
become  closed,  these  assertions  place  no  restrictions  on  the  behavior  of  the  doors. 

-  State  Predicate 
Vt,  i : 

on.floor(i,t) 

implies 

doors.open(i,t )  =  lift.open(t) 
and  doors.opening(i,t)  =  lift.opening(t ) 
and  doors.closed(i,t )  =  lift.closed(t ) 
and  doors.closing(i ,  t )  =  lift.closing(t) 
and  doors.obstructed(i,t )  =  lift.obstructed(t ) 
and  Vj  such  that  j  ^  i  :  (doors.closed(j,  t)  and  lift.closed(t )) 

-  All  doors  are  closed  when  the  elevator  is  in  motion. 

There  is  no  analogue  to  this  assertion  in  the  ITL  specification. 

Vt,  i : 

above.floor(i,  t ) 
implies 

lift.closed(t) 
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and  Vj  :  doors.closed(j,  t) 

-  The  doors  become  open  within  time  opening  Jime  of  when  they  began  opening. 

*  ITL 

fopening(a)  =>  open(a)]  □  inservice  D<  openingJime 

This  is  an  incorrect  formalization  of  the  assertion  in  ITL.  As  noted  earlier,  if 
the  doors  begin  opening  and  never  subsequently  become  open,  then  the  above 
assertion  is  defined  to  be  vacuously  true.  Thus,  instead  of  saying  that  the  doors 
must  become  open  within  time  opening-time ,  the  ITL  assertion  actually  requires 
that  if  the  doors  become  open  at  some  later  point,  then  they  must  have  become 
open  within  time  openingJime.  Consequently,  the  ITL  assertion  does  not  even 
require  that  the  doors  become  open  at  some  later  point.  The  correct  way  to 
formalize  this  assertion  in  ITL  is: 

[opening (a)  =>  opening(a)  +  openingJimeJO  (->  inserviceS/  open(a) 

This  says  that  within  openingJime  of  when  the  doors  become  opening,  they  either 
become  open  or  the  elevator  becomes  out  of  service. 

*  State  Predicate 
V*i,i  : 

doors-opening(i,  tj) 
implies 

3*2  €  (*i,*i  +  openingJime )  :  doors.open(i,  t2) 

f.  The  doors  become  closed  within  time  closingJime  of  when  they  began  closing  unless  they 
are  obstructed  in  the  meantime. 

-  ITL 

closing  (a)  =>  closed(a)]  □  (inservice  A->  obstructed  (a))  D<  closingJime 

This  has  the  same  type  of  error  as  the  ITL  specification  of  the  previous  assertion. 

-  State  Predicate 

V*i,i : 

doors.closing(i,  *1) 

and  V*  €  (*x,*i  +  closingJime)  :  -‘doors.closed(i,t ) 
implies 

3*2  €  (*i,*i  +  closingJime)  :  doors-obstructed(i, *2) 
g.  When  the  doors  become  obstructed,  they  begin  opening  within  time  reactionJime. 

-  ITL 

(obstructed(a)  =$■  opening  (a)]  □  inservice  D<  reactionJime 

This  contains  the  same  type  of  flaw  as  the  ITL  specification  for  the  previous  assertion. 
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-  State  Predicate 
Vti.i : 

doors.obstrvcted{i,  ti) 
implies 

3<2  €  +  reaction-time )  :  doors-opening(i,t2 ) 

h.  When  the  doors  become  open  as  a  result  of  being  obstructed,  they  begin  closing  within 
time  dwell-time  of  when  they  become  open. 

-  ITL 

[(obstructed(a)  =>  open(a))  =>  closing  (a)]  □  inservice  supset  <  dwelLtime 

This  contains  the  same  type  of  flaw  as  the  ITL  specification  for  the  previous  assertion. 

-  State  Predicate 
Vt\,t2,i  : 

doors-obstructed(i,  t\) 
and  Vf  €  (^1,^2)  :  ~'doors-open(i,t) 
and  doors-open(i,t2 ) 
and  tj  <  t2 
implies 

3*3  €  (*2 1  *2  +  dwelLtime )  :  doorS-closing(i,  *3) 

i.  The  time  between  when  the  doors  become  open  at  a  floor  and  when  they  begin  closing  is 
at  least  min-openJime. 

ITL 

[open(a)  =>  closing  (a)]  >  min-openJime 

This  contains  the  same  type  of  flaw  as  the  ITL  specification  for  the  previous  assertion. 

-  State  Predicate 
V<ii *2, *3, l  • 

Vt  6  (*1 , *2)  :  ~'doors-open(i,t\) 
and  doors.open(i,t2 ) 
and  doors -closing(i,  *3) 
and  t-i  <  t2  <  *3 
implies 

*3  —  *1  >  min-openJime 
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j.  The  doors  can  only  be  obstructed  when  they  are  closing. 

-  ITL 

[obstructed(a)  =>  )  closing(a) 

-  State  Predicate 
Vi  : 

lift.obstructed(t)  implies  lift.closing(t) 
and  Vi  :  doors. obstructed(i,  t)  implies  doors.closing(i,t) 

-  When  the  elevator  reaches  a  floor  for  which  there  is  a  pending  request,  the  doors  begin 
opening. 

li  <  ti 

and  Vt  €  (<1,^2)  :  ~'on.floor(i,t) 
and  on.floor{i,t2 ) 
and  request.light(i ,  t2) 

implies 

doors  .opening(i ,  f2) 

•  Constraints  on  change  of  direction: 

a.  The  elevator  can  only  change  direction  from  down  to  up  when  there  are  no  requests 
pending  at  a  lower  floor. 

-  ITL 

b  <  a  D  [ before  goingup  =>  atfloor(a)  D  ->  light  (b,  dir)  10 

-  State  Predicate 

V*i,*2 ,i,j  ■ 

V<3  €  [<1 ,  <2)  1  going .up(t3) 
and  going.up(t2 ) 
and  either: 

( on.floor[i ,  t2 )  and  j  <  i) 
and  (above .floor(i,t2)  and  j  <  i ) 

implies 

-^request Jight(j,  t2) 

I0The  predicate  goingup  is  used  in  the  ITL  model  to  denote  the  event  that  the  elevator  has  decided  to  change 
directions  and  move  upwards. 
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b.  The  elevator  can  only  change  direction  from  up  to  down  when  there  are  no  requests 
pending  at  a  higher  floor. 

-  ITL 

b  >  a  D  [before^ goingup  =>  atfloor(a)  D  ->  light  (b,  dir ) 

-  State  Predicate 

Vtut2,i,j  : 

W3  €  [t\,ti)  :  going jup{tz) 
and  ~i going jup(t2) 
and  either: 

(on~floor(i,  t2)  and  i  <  j 
or  ( above.floor[i  —  1,^)  and  i  <  j) 
implies 

~>requestJight(j ,  t2) 

c.  The  elevator  cannot  reverse  directions  when  it  is  between  floors. 

Since  the  ITL  specification  does  not  allow  the  elevator  to  be  between  floors,  this  assertion 
is  not  represented  in  the  ITL  specification. 

Vt  : 

reverse(t ) 
implies 

3 i  :  on..floor{i,t ) 

3. 2. 2. 2  Elevator  Service  Policy —  We  olace  the  following  requirements  on  the  service  pro¬ 
vided  by  the  elevator: 

•  ITL 

[ newrequest(a,dir )  =>  newrequest(a,dir)  +  maxserviceJimeJ  □  (inservice  A-> obstructed) 
*  open(a) 

This  asserts  that  in  the  interval  of  length  maxserviceJime  starting  with  a  new  request 
for  service  at  floor  a,  the  doors  will  open  at  least  once  at  floor  a  if  and  only  if  no  doors 
are  obstructed.  It  is  unreasonable  to  require  that  there  were  not  any  obstructions  if  the 
doors  open  within  time.  For  example,  maxserviceJime  must  be  relatively  large  for  a 
building  with  many  floors.  Then,  if  the  elevator  is  at  floor  0  when  a  request  is  made  at 
floor  1,  it  is  quite  possible  that  the  doors  might  be  temporarily  obstructed  at  floor  0  and 
still  arrive  at  floor  1  within  time.  So,  it  seems  that  simply  requiring  that  if  the  doors  are 
not  obstructed,  then  they  will  open  at  least  once  is  a  more  reasonable  policy.  This  is  the 
policy  that  we  use  in  are  model. 


66 


•  State  Predicate 

If  no  doors  are  obstructed  in  the  meantime,  the  elevator  will  service  a  floor  within  time 
maxserviceJime  of  a  request  for  service  at  that  floor. 

up_requested(i,t)  or  down.requested(i,  t)  or  floor. requested(i,t) 

and  Vtj  €  [M  +  rnax.service.time]  :  servicing,  t\) 

implies 

3*2  6  [f,  t  +  maxservice-time ]  :  lift-obstructedfa ) 


3. 2. 2. 3  Analysis  of  Elevator —  The  proof  of  the  service  policy  for  the  elevator  follows  after 
showing  that  there  exists  an  appropriate  constant  M  such  that  the  following  lemmas  hold: 

a.  If  the  elevator  is  at  floor  i  or  between  floor  i  —  1  and  floor  i  and  going  down,  then  it  will 
reach  floor  0  within  time  i  x  M  unless  it  reverses  directions,  a  set  of  doors  is  obstructed,  or 
all  requests  have  been  serviced  in  the  meantime. 

ii.t\  : 


( on.floor{i,ti )  or  above.floofli  —  l,*i)) 
and  -i going. up(*i) 

and  it  €  (*i,*i  +  i  X  M)  :  -> on.floor(0,t ) 
implies 

3*  +  i  x  M)  : 

(reverse(t)  or  lift-obstructed(t )  or  (ij  :  -‘request Jight(j,t))) 

b.  If  the  elevator  is  at  or  above  floor  i  and  going  up,  then  it  will  reach  floor  MAXfioor  within 
time  (M AX fiOOT  -  i)  x  M  unless  it  reverses  directions,  a  set  of  doors  is  obstructed,  or  all 
requests  have  been  serviced  in  the  meantime. 

Vi,  1 1  : 


(on.floor{i ,  ti)  or  above. floor(i,ti)) 
and  going _up{t\) 

and  it  e  +  ( MAXfi00r  -  i)x  M)  :  ~‘on.floor{M  AX  floor, i) 

implies 

3*  €  (*i,*i  +  (MAXfioor  ~  *)  x  M )  : 

(reverse(t)  or  lift.obstructed(t)  or  (ij  :  -‘request Jight(j,t))) 
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c.  If  the  elevator  arrives  on  a  floor  for  which  there  is  a  request  pending,  the  doors  become  open 
within  time  M. 

Vt  €  (ti,t2)  :  -'on-floor(i,t) 
and  on.floor(i,t2 ) 
and  request Jight(i,t2) 
implies 

3*3  €  (*2>  *2  +  Af)  :  doors.open(i,t3 ) 

Our  goal  is  to  show  that: 

If  the  doors  are  not  obstructed  during  the  interval  of  length  maxserviceJime  starting  when 
a  request  is  made,  then  the  request  is  serviced  at  some  time  during  that  interval. 

We  will  assume  that: 

2  X  M  x  (MAX jioor  +  1)  <  maxserviceJime. 

The  system  parameters  must  be  chosen  so  that  lemmas  a-c  hold  for  some  such  value  of  M  to 
validate  this  analysis. 

Since  we  only  consider  times  at  most  maxserviceJime  time  units  after  when  service  is  requested  in 
the  following  analysis,  we  can  assume  without  loss  of  generality  that  the  doors  are  not  obstructed. 
Consequently,  we  ignore  the  possibility  of  the  doors  becoming  obstructed  in  the  following  analysis. 

The  analysis  begins  by  assuming  that  a  request  has  been  made  at  floor  i.  Suppose  that  the  elevator 
is  at  or  below  floor  j  and  traveling  down  when  the  request  is  made.  If  i  is  below  j,  then  the  elevator 
may  not  change  directions  until  the  request  is  serviced.  Thus,  lemma  a  ensures  that  within  time 
i  x  M  the  request  is  either  serviced  or  the  elevator  reaches  floor  0.  In  order  for  the  elevator  to  reach 
floor  0,  it  previously  .  est  have  passed  through  floor  t.  Then,  lemma  c  ensures  that  the  request  is 
serviced  within  time  i  M  +  M.  In  either  case,  the  request  is  serviced  in  time  ( i  +  1)  x  M. 

Now,  suppose  that  i  is  above  j.  Then,  within  time  j  x  M  +  M  it  either  reverses  direction  or  reaches 
the  bottom  floor  and  reverses  direction  (by  lemma  a).  Then,  analysis  similar  to  that  used  in  the 
previous  case  shows  that  the  floor  will  be  serviced  within  time  (i+j  +  2)  x  A/11.  The  analysis  for  the 
case  in  which  the  elevator  is  initially  travelling  upwards  is  similar.  Since  i  +  j  <  2  x  MAXfioor  and 
we  are  assuming  that  maxserviceJime  >  2  x  M  x  (M AX jiOOT  +  1),  the  service  policy  is  satisfied. 

Thus,  the  analysis  is  reduced  to  finding  a  value  for  M  suitable  for  justifying  the  lemmas.  It  suffices 
to  choose  M  such  that  it  is  greater  than  the  maximum  time  between  leaving  a  floor  and  leaving 
the  next  floor  while  a  request  is  pending.  So,  M  must  be  large  enough  to  address  the  movement 
time  between  floors,  the  opening  time  for  doors,  the  time  doors  remain  open,  and  the  closing  time 
for  doors.  This  means  that  M  must  be  chosen  so  that  it  is  larger  than: 

"Lemma  b  ensures  the  request  will  be  serviced  within  time  («  +  1)  x  M  from  its  arrival  at  floor  0 
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movement-time  +  opening-time  +  max-openJtime  +  closing-time 

to  satisfy  lemmas  a-c.  Combining  this  with  our  earlier  analysis,  we  see  that  the  service  policy  holds 
whenever: 

2  x  ( movement-time  -f  opening-time  +  max-open-time  +  closing Jime)  x  ( MAXjioot  +  1) 

<  maxservice-time 


3.2.3  Summary  of  the  Example 

In  this  section  we  have  provided  an  example  of  a  real-time  system  and  policy.  Although  the  system 
and  policy  are  relatively  simple,  they  are  complex  enough  to  provide  a  nontrivial  example.  The 
example  demonstrates  how  a  set  of  relatively  simple  conditions  can  be  generated  that  imply  the 
satisfaction  of  a  real-time  policy.  Rather  than  directly  showing  the  elevator’s  service  policy  is 
satisfied,  it  suffices  to  show  that: 

2  x  ( movement-time  -f  opening-time  -f  max-openJime  -f  closing-time)  X  (M AX jiOOT  -f  1) 

<  maxservice-time 

and  that  the  model  of  the  elevator  is  consistent  with  the  real  elevator. 

By  providing  the  ITL  specifications  along  with  the  state  predicates,  we  make  it  possible  to  compare 
ITL  with  state  predicates.  Although  ITL  is  more  concise,  it  suffers  from  two  disadvantages. 

First,  it  is  more  difficult  to  write  an  ITL  specification.  The  ITL  specification  in  [17]  contained  several 
errors  that  were  difficult  to  find  due  to  the  difficulty  in  humans  interpretting  ITL  specifications. 
Simple  ITL  specifications  are  very  understandable,  but  the  more  complex  specifications  are  very 
difficult  to  decipher.  While  the  state  predicates  are  less  concise,  it  is  easier  to  determine  the 
correctness  of  a  state  predicate  model  since  it  is  easier  to  interpret  the  specifications. 

Second,  [17]  does  not  describe  any  proof  rules  for  ITL.  Thus,  it  is  not  clear  how  an  analysis  such 
as  that  provided  for  the  state  predicate  model  could  be  performed  on  the  ITL  specification.  [17] 
addresses  this  by  making  use  of  the  decidability  of  the  logic  to  argue  that  it  is  feasible  to  develop  a 
tool  that  can  automatically  analyze  an  ITL  model.  The  premise  seems  to  be  that  such  a  tool  would 
make  proof  rules  unnecessary.  It  seems  unlikely  that  a  completely  automated  tool  could  analyze 
the  ITL  specification  of  a  complex  system  in  a  reasonable  amount  of  time.  The  current  state  of 
the  art  is  such  that  totally  automated  theorem  provers  are  very  weak.  This  would  mean  that  a 
human  would  need  to  develop  a  proof  strategy  to  simplify  the  analysis.  Since  there  currently  are  no 
proof  rules,  the  human  would  have  to  translate  the  ITL  specifications  to  a  more  primitive  notation 
such  as  our  state  predicates.  Then,  any  advantage  of  using  ITL  is  lost.  This  disadvantage  can  be 
addressed  if  a  nice  set  of  proof  rules  can  be  developed  for  ITL. 

Thus,  the  state  predicate  approach  is  the  most  useful  of  the  approaches  we  considered  for  stating 
and  proving  real-time  polcies. 
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3.3  SUMMARY  OF  AVAILABILITY  MODELS 


In  this  section  we  have  addressed  fault  tolerance,  classes  of  denial  of  service  threats,  and  provided 
a  worked  example  of  the  specification  and  analysis  of  a  real-time  system. 

The  policies  developed  for  fault  tolerance  and  liveness  are  quite  general.  They  both  make  use  of 
the  CSP  formalism  which  we  found  to  be  the  most  useful  for  developing  availability  policies  for 
distributed  systems,  with  the  exception  of  real-time  policies.  Our  approach  for  using  these  policies 
to  analyze  a  system  is: 

a.  Develop  a  CSP  specification  of  the  system  ignoring  the  possibility  of  faults. 

b.  Determine  the  set  of  faults  to  be  tolerated  and  the  effects  of  each  fault. 

c.  Extend  the  CSP  specification  of  the  system  to  address  the  possibility  of  faults. 

d.  Demonstrate  that  the  system  satisfies  our  fault  tolerance  policy.  Since  this  demonstrates  that 
no  new  behaviors  are  introduced  by  faults,  the  possibility  of  faults  can  be  ignored  in  any 
subsequent  analysis. 

e.  Demonstrate  that  the  CSP  specification  that  ignores  the  possibility  of  faults  satisfies  any  of 
our  availability  policies  that  are  desired. 

As  discussed  previously,  further  research  is  needed  to  determine  possible  extensions  to  our  policies 
that  might  be  required  to  address  nondeterminism.  A  complete  worked  example  of  the  above 
approach  must  be  developed,  too.  This  would  provide  validation  for  the  policies  and  the  approach 
and  allow  any  inadequacies  to  be  addressed.  Since  a  similar  worked  example  must  be  done  to 
validate  the  security  policies  developed  in  [4],  Distributed  Trusted  Mach  and  Theta-DOS  are  the 
obvious  candidates  for  the  worked  example.  Although  both  of  these  systems  are  too  complex  to 
perform  a  complete  analysis  as  a  proof  of  concept,  a  representative  set  of  servers  could  be  analyzed 
to  validate  our  approach. 

The  same  must  be  done  for  our  work  with  real-time  policies.  A  moderately  complex  application 
with  real-time  constraints  must  be  identified  to  serve  as  a  more  realistic  worked  example  of  the 
approach. 

Armed  with  the  availability  policies  developed  in  this  section  and  the  security  policies  developed 
in  [4],  we  are  now  ready  to  consider  making  trade-offs  between  security  and  denial  of  service. 
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SECTION  4 


TRADE-OFFS 


In  [5]  a  detailed  analysis  was  made  of  possible  ways  to  deny  service  in  a  distributed  system.  As  part 
of  the  analysis,  known  techniques  for  preventing  these  denial  of  service  attacks  were  examined,  and, 
for  each  technique,  the  possible  security  implications  were  discussed.  In  this  section  we  summarize 
some  of  the  basic  trade-offs  that  necessarily  occur  when  attempting  to  provide  both  MLS  security 
and  a  high  degree  of  assured  service.  We  also  examine  some  approaches  to  security  policy  issues 
that  can  be  used  when  confronted  with  these  trade-offs. 

The  definition  given  in  [5]  for  denial  of  service  is  that  the  system  does  not  satisfy  its  specifications. 
Such  specifications  are  usually  functional  and  stated  in  terms  of  specific  actions,  responses  and 
response  times  that  the  system  must  provide.  On  the  other  hand,  the  security  policy  for  a  system  is 
usually  a  higher  level  policy  that  is  stated  in  terms  of  information  flow  in  a  more  abstract  manner[7], 
and  the  implications  of  such  a  policy  are  often  not  immediately  obvious.  This  is  necessary  because 
the  concept  of  illegal  information  flow  that  the  definition  is  attempting  to  capture  is  subtle  and  not 
easily  recognized  from  functional  specifications. 

In  an  MLS  distributed  system,  the  challenge  is  to  satisfy  both  the  denial  of  service  policy  and  the 
security  policy.  There  are  areas  in  which  the  policies  are  mutually  supportive.  For  example,  tech¬ 
niques  aimed  at  protecting  the  integrity  of  data  on  the  system  help  guarantee  that  neither  service 
is  denied  nor  security  is  compromised  based  on  corrupted  data.  Unfortunately,  other  techniques 
used  to  ensure  that  one  policy  is  satisfied  may  often  lead  to  the  second  policy  being  violated.  Some 
of  the  most  common  reasons  for  this  are: 

•  Shared  Finite  Resources.  In  a  system  in  which  processes  share  system  resources,  the  po¬ 
tential  exists  for  service  denial  based  on  one  process  accumulating  and  holding  these  system 
resources.  A  number  of  techniques  have  been  developed  to  prevent  such  an  occurrence.  How¬ 
ever,  most  of  these  techniques  involve  some  type  of  approach  that,  in  an  MLS  system,  could 
be  used  to  signal  information  from  a  high  level  to  a  low  level  subject. 

•  System  Algorithms.  Algorithms  that  control  system-wide  processing,  e.g.  scheduling  al¬ 
gorithms  or  communication  protocols,  often  involve  communication  among  processes  that,  in 
an  MLS  system,  may  be  at  different  levels.  The  danger  exists  that  this  processing  can  be 
manipulated  to  signal  information  from  high  to  low. 

•  Shared  Data  Structures.  Techniques  for  both  sharing  system  resources  and  performing 
system-wide  processing  often  rely  on  shared  data  structures  for  maintaining  control  informa¬ 
tion.  If  these  data  structures  are  global,  then  they  present  a  potential  security  problem. 

The  above  conflicts  between  assuring  service  and  maintaining  a  secure  system  lead  to  a  number  of 
trade-offs  that  may  be  necessary.  These  trade-offs  could  result  in  either  the  security  policy  or  the 
assured  service  policy  being  modified. 

Security  Policy  Trade-offs. 
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To  provide  the  degree  of  service  that  the  system  requires,  it  may  be  necessary  to  make  modifications 
to  the  security  policy  that  the  ystem  is  designed  to  enforce.  There  are  a  number  of  possible  ways 
in  which  this  could  be  done. 


•  Trusted  Subjects.  To  provide  assured  service,  it  may  be  necessary,  or  desirable,  to  use  a 
technique  that  requires  that  information  be  written  at  several  levels  or  that  communication 
occur  across  levels.  If  ordinary  subjects  were  allowed  to  do  this,  then  they  would  have  the 
potential  to  easily  pass  information  from  a  high  to  a  low  level.  By  encapsulating  the  processing 
in  a  special  subject,  which  is  identified  as  a  trusted  subject,  and  then  analyzing  the  processing 
that  this  subject  does  to  ensure  that  its  special  privileges  cannot  be  misused,  it  is  sometimes 
possible  to  minimize  the  security  risk  of  the  operation.  Trusted  subjects  typically  represent 
the  exceptions  to  the  systems  access  control  policy. 

•  Allow  Covert  Channels.  In  certain  systems,  the  dangers  that  a  covert  channel  poses  may 
be  minimal  compared  to  the  effort  required  to  exploit  the  channel.  If  it  is  known  that  covert 
channels  are  not  a  major  concern  of  the  system,  then  an  access  control  policy,  such  as  the 
Bell  and  LaPadula  policy  [1],  that  is  not  concerned  with  covert  channels  could  be  used.  The 
danger  in  this  approach  is  that  since  there  is  no  attempt  to  identify  covert  channels,  there  is 
no  real  way  of  knowing  whether  the  assumption  that  such  channels  are  not  a  major  threat  to 
the  security  of  the  system  is  valid. 

•  Allow  Restricted  Covert  Channels.  In  most  systems  it  may  not'be  possible,  or  desirable, 
to  eliminate  all  downward  information  flows.  Hence,  a  strict  information  flow  policy  that 
says  that  there  is  no  flow  from  high  to  low  would  not  be  provable.  In  such  cases,  it  may  be 
possible  to  modify  the  definition  of  noninterference  so  that  that  the  particular  information  flow 
is  removed  from  the  policy  statement.  Using  this  modified  information  flow  policy  it  is  then 
possible  to  continue  the  search  for  other  unauthorized  information  flows.  Three  techniques 
that  may  be  useful  are: 

Conditional  noninterference. 

Effectively  ignoring  channels. 

Probabilistic  noninterference. 

Conditional  Noninterference.  In  [7]  the  notion  of  Conditional  TH-Guardedness  was 
introduced  to  provide  an  information  flow  policy  that  allowed  well-identified  exceptions  to 
the  policy.  Such  a  conditional  noninterference  policy  states  that  except  for  certain  privileged 
operations  there  is  no  information  flow  from  a  high  to  a  low  level.  These  privileged  operations 
can  then  be  analyzed  individually  to  determine  the  risk  involved  with  each.  While  some  of  the 
operations  trusted  to  violate  a  system’s  access  control  policy  might  be  included  in  this  set  of 
privileged  operations,  [4]  demonstrates  that  not  all  trusted  operations  downgrade  information. 
It  also  is  possible  that  some  of  the  privileged  operations  are  not  trusted  operations.  So, 
although  there  is  some  similarity  between  the  notion  of  trusted  subjects  and  subjects  privileged 
to  violate  noninterference,  they  are  independent  concepts. 
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Effectively  Ignoring  a  Channel.  A  well-known  potential  covert  channel  involves  the  iden¬ 
tifier  that  is  generated  when  a  new  object  or  subject  is  created  on  the  system  [10].  If  a  low 
level  process  creates  an  object,  waits,  then  creates  a  second  object,  by  comparing  the  ids  of 
the  objects  created,  the  process  can  determine  if  any  other  objects  or  subjects  were  created  in 
between.  So  by  either  creating  an  object  or  not  between  the  time  when  the  low  level  objects 
are  created,  a  high  level  subject  can  signal  to  the  low  level  subject.  While  this  is  an  obvious 
covert  channel,  it  may  not  be  of  much  interest  on  the  system  if,  for  example,  the  identifiers 
are  encrypted  so  that  the  order  in  which  they  are  generated  is  not  recognizable. 

It  is  possible  to  abstract  out  from  the  information  flow  analysis  known  covert  channels  present 
in  the  system  that  are  not  of  interest.  This  approach  has  been  called  effectively  ignoring  the 
channel  [20].  The  idea  is  that  when  a  high  level  operation  occurs,  its  effects  should  not 
be  visible  to  any  lower  level  subject  except  for  the  results  of  the  particular  known  channel. 
That  is,  it  should  be  possible  to  effectively  ignore  the  operation  at  the  lower  level  except  for 
the  change  made  through  the  channel.  This  allows  one  to  define  an  information  flow  policy 
that  can  still  be  proven  even  in  the  presence  of  known  covert  channels.  The  technique  clearly 
identifies  these  channels  and,  at  the  same  time,  allows  the  information  flow  analysis  to  continue 
on  the  remainder  of  the  system.  The  technique  differs  from  conditional  noninterference  in  that 
in  the  later  the  entire  operation  is  excluded  from  the  noninterference  analysis,  while  in  the 
former,  only  that  part  of  the  operation  that  results  in  the  channel  is  excluded.  For  the 
identifier  example,  the  high  level  operations  that  create  new  objects  and  subjects  can  be 
effectively  ignored  except  for  the  effect  that  they  have  on  the  generation  of  future  identifiers. 
This  allows  the  remainder  of  these  operations  to  still  be  part  of  the  noninterference  analysis. 
Stochastic  Policies.  In  [7]  we  defined  a  stochastic  information  flow  policy  that  required: 

For  any  sequence  of  inputs  and  low-level  outputs,  the  probability  that  the  system  will 
generate  the  given  sequence  of  low-level  outputs  from  the  sequence  of  inputs  is  the 
same  as  the  probability  the  system  will  generate  the  low-level  output  sequence  from 
only  the  low-level  inputs  of  the  given  input  sequence. 

Illegal  information  flow  would  occur  if  the  above  described  probabilities  were  not  the  same 
indicating  that  some  high-level  event  affected  the  low-level  outputs. 

In  [15]  Gray  presents  a  different  version  of  such  a  stochastic  policy,  called  P-restrictiveness, 
and  suggests  that  by  altering  the  probabilities  that  certain  events  occur  in  a  system,  it  may 
be  possible  to  satisfy  a  stochastic  information  flow  policy  while  at  the  same  time  limiting 
certain  denial  of  service  attacks.  In  particular,  the  example  that  is  discussed  is  the  classic 
reader-writer  problem  in  which  a  data  object  is  being  written  by  a  low-le\el  process  and  read 
by  a  high-level  process. 

Since  readers  and  writers  cannot  both  access  the  data  object  at  the  same  time,  some  protocol 
must  be  used  to  synchronize  the  accesses.  To  prevent  downward  information  flow,  if  a  low- 
level  writer  requests  to  write  the  data  object,  then  any  high-level  readers  that  are  currently 
accessing  the  object  are  preempted.  This  presents  the  possibility  that  high-level  readers  can 
be  permanently  denied  access  to  the  data  by  the  actions  of  low-level  writers. 

Gray  proposes  that  this  denial  of  service  problem  may  be  partially  addressed  by  controlling 
the  probabilities  with  which  certain  events  can  occur  in  the  system.  In  the  example,  by 
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requiring  that  specific  inputs  be  polled  for,  it  is  possible  to  guarantee  that  the  write  request 
from  the  low-level  process  only  be  serviced  a  certain  percentage  of  the  time,  say  p.  (If  a 
request  is  not  serviced,  it  may  be  serviced  at  a  later  time.  In  effect,  servicing  of  the  request  is 
delayed.)  When  the  low-level  write  request  is  finally  serviced,  of  course,  all  current  high  level 
readers  are  preempted,  but  the  idea  is  that,  in  the  meantime,  the  high-level  process  may  be 
given  a  longer  time  to  complete  its  read.  The  intent  is  that  the  high-level  process  will  not  be 
preempted  as  often. 

Although  the  stochastic  information  flow  policy  is  relatively  new  and  needs  further  develop¬ 
ment,  as  mentioned  in  [7],  there  are  a  number  of  serious  difficulties  with  it.  Moreover,  there 
appear  to  be  a  number  of  difficulties  in  attempting  to  use  such  a  policy  to  prevent  denial  of 
service  also. 

a.  Determining  the  appropriate  probabilities  to  assign  to  each  event  is  a  difficult  process.  As 
the  example  in  [15]  shows,  unless  the  probabilities  are  determined  in  exactly  the  right 
manner,  the  stochastic  information  flow  policy  will  not  be  satisfied. 

b.  The  system  must  then  enforce  that  the  appropriate  events  occur  with  the  required  prob¬ 
abilities.  This  may  complicate  the  implementation  considerably. 

c.  The  approach  suggested  has  the  effect  of  slowing  the  entire  system  down.  Events  can 
only  occur  with  a  given  probability.  If  the  system  is  in  a  state  in  which  there  is  only  one 
possible  event,  and  if  that  event  can  only  occur  with  probability  p,  then  1-p  of  the  time, 
the  system  will  have  to  wait. 

d.  In  the  end,  the  approach  may  not  prevent  denial  of  service.  The  reader-writer  problem 
is  basically  a  problem  in  concurrent  access.  As  such,  it  is  time  dependent.  Depending  on 
the  length  that  the  read  request  takes,  it  may  be  possible  for  a  malicious  low-level  writer 
to  still  interrupt  it  before  it  is  finished  most  of  the  time. 

The  last  two  points  indicate  that  the  effect  of  juggling  the  probabilities  with  which  certain 
events  on  the  system  can  occur  is  basically  equivalent  to  slowing  down  the  frequency  with 
which  the  low-level  process  can  request  a  write  and,  thereby,  pose  a  denial  of  service  threat. 
An  alternate  approach  that  would  be  simpler,  have  the  same  effect,  and  avoid  the  probabilistic 
complications,  would  be  to  just  put  a  time  delay  on  any  write  request.  When  the  write  request 
is  made,  delay  a  fixed  time  before  actually  servicing  the  request.  This  would  allow  any  high- 
level  reads  a  fixed  amount  of  time  to  complete  before  they  are  preempted.  Of  course,  just  as 
with  the  probabilistic  approach,  reads  that  did  not  finish  in  time  would  be  preempted. 

•  Provide  a  Heterogeneous  Policy.  In  a  distributed  system  composed  of  heterogeneous 
nodes,  it  may  not  be  possible  to  prove  a  policy  that  holds  for  all  nodes,  or,  alternatively, 
the  policy  that  is  proven  may  only  be  as  strong  as  the  weakest  node.  An  alternate  approach 
might  be  to  prove  the  strongest  policy  that  is  possible  for  each  node,  and  then  identify  the 
manner  in  which  the  weaker  nodes  can  compromise  the  system  and  attempt  to  address  these 
threats  on  an  individual  basis. 


Assured  Service  Trade-offs. 


If  it  is  determined  that  a  potential  covert  channel  should  be  eliminated  from  the  system  because  it 
poses  too  great  a  threat  to  the  security  of  the  system,  then  a  number  of  possible  approaches  may 
be  taken  depending  on  which  is  most  appropriate.  All  of  these  approaches  will,  to  one  degree  or 
another,  affect  the  level  of  service  that  the  system  can  provide. 

•  Restrict  Access  to  Shared  Resources.  For  resources  that  are  abundant  enough  that 
they  can  be  partitioned  among  levels,  it  may  be  possible  to  statically  allocate  quotas  of  the 
resource  among  the  levels  so  that  the  sum  of  the  quotas  never  exceeds  the  total  amount  of  the 
resource.  This  eliminates  the  channel  at  the  expense  of  disallowing  all  sharing  of  the  resource. 
Such  an  approach  was  used  by  Multics  in  allocating  directory  space. 

A  variation  of  this  strategy  would  involve  allowing  higher  level  processes  to  use  lower  level 
quotas  that  were  currently  unused.  When  a  lower  level  process  desired  the  use  of  the  resources, 
however,  the  system  would  have  to  preempt  them  from  the  higher  level  process. 

•  Preempt  High  Level  Processes.  For  shared  resources,  this  approach  is  similar  to  the 
variation  mentioned  above  except  that  there  are  no  quotas  at  any  level.  The  resource  being 
shared  is  allocated  on  a  first  come,  first  serve  basis.  However,  to  prevent  a  high  level  process 
from  signalling  a  low  level  process  by  using  all  the  resource,  whenever  a  low  level  process 
requests  the  resource  and  there  is  none  available,  a  high  level  process  that  has  the  resource 
allocated  may  have  to  relinquish  it.  This  prevents  the  covert  channel  at  the  expense  of 
causing  the  high  level  process  to  face  possible  starvation  because  it  cannot  retain  control  of 
the  resource  long  enough  to  finish  its  processing. 

•  Per  Level  Algorithms.  Rather  than  implement  system-wide  algorithms  that  require  access 
to  information  at  multiple  levels,  it  may  be  possible  to  modify  the  algorithms  so  that  the 
processing  can  be  done  on  a  level  by  level  basis  with  minimal  communication  across  levels. 
For  example,  it  should  be  possible  to  implement  recovery  algorithms  on  a  level  by  level  basis. 

•  Use  Stale  Data.  For  data  that  is  being  shared  across  levels,  that  is,  read  by  higher  level 
processes  and  written  by  low  level  processes,  the  concern  is  that  the  higher  level  processes 
access  consistent  data.  If  a  low  level  process  is  in  the  act  of  updating  data,  then  the  high  level 
process  must  wait  until  the  update  has  been  completed  or  risk  getting  data  that  is  inconsistent. 
This  again  presents  the  possibility  that  the  high  level  processes  can  be  indefinitely  postponed. 
One  method  of  avoiding  this  would  be  to  keep  older,  consistent,  versions  of  the  data  available 
for  the  high  level  processes  to  read.  This  allows  the  high  level  processes  to  complete  their 
processing  but  at  the  expense  of  using  data  that  may  be  out  of  date.  For  a  real-time  C2 
application,  however,  this  may  not  be  appropriate.  Another  possibility  would  be  to  inform 
the  application  that  the  data  is  stale  and  let  it  decide  whether  to  roll  back. 

•  Audit  and  Regulate.  In  many  cases,  it  may  not  be  feasible  to  completely  eliminate  a 
potential  information  flow  from  high  to  low.  However,  it  may  be  possible  to  identify  when 
such  a  flow  can  occur  and  audit  it.  If  the  audit  mechanism  is  sophisticated  enough,  it  may  also 
be  possible  to  identify  when  the  channel  is  being  exploited  and  react  appropriately.  Regulating 
the  degree  to  which  the  channel  can  be  used  might  also  be  done  via  time  delays. 

This  approach  has  two  drawbacks. 
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a.  It  results  in  certain  parts  of  the  system  being  slowed  down  which,  in  practice,  might  limit 
service  availability. 

b.  It  can  only  be  used  on  operations  that  can  be  audited.  Operations  that  occur  so  frequently 
that  it  would  be  infeasible  to  audit  them,  such  as  disk  accesses,  could  not  be  handled  in 
this  manner. 

In  summary  then,  trade-offs  between  security  and  assured  service  seem  inevitable.  A  security 
analysis  that  uses  conditional  noninterference,  augmented  by  analyzing  trusted  subjects  and  by 
effectively  ignoring  certain  aspects  of  operations,  would  seem  to  give  the  most  complete  analysis 
while  allowing  enough  flexibility  to  make  compromises  to  assured  service  when  necessary.  Channels 
can  be  isolated  and  identified  and,  if  necessary,  audited  and  regulated.  In  some  cases,  heterogeneous 
policies  may  be  necessary.  The  trade-offs  for  assured  service  are  less  clear  and  usually  must  be  dealt 
with  on  a  per  situation  basis.  In  particular,  this  might  involve  changing  specifications  to  allow  for 
some  time  delays. 

To  demonstrate  the  usefulness  of  the  approaches  for  performing  trade-offs,  an  example  should  be 
worked  of  a  reasonably  complex  system  that  has  been  analyzed  w'th  respect  to  both  availability 
and  security  policies.  Due  to  the  generality  of  the  approaches  for  performing  trade-offs,  this  would 
provide  very  useful  guidance  to  developers  and  evaluators  of  distributed,  secure  systems. 


SECTION  5 


CONCLUSION 


In  this  report  we  have: 

«  Discussed  various  formalisms  that  might  be  used  for  specifying  and  analyzing  C2  systems. 

•  Described  an  approach  for  analyzing  such  systems  with  respect  to  fault  tolerance. 

•  Developed  policies  to  address  classes  of  denial  of  service  threats  including  starvation,  deadlock, 
mutual  starvation,  and  likelock. 

•  Provided  an  example  of  a  real-time  system  and  policy. 

•  Discussed  trade-offs  that  can  be  made  between  security  and  denia1  of  service. 

Of  the  formalisms  we  have  considered,  CSP  seem  the  most  appropriate  for  use  with  C2  systems. 
Unfortunately,  it  does  not  appear  reasonable  to  add  real-time  to  CSP.  Real  Time  Logic  (RTL) 
and  Interval  Temporal  Logic  (ITL)  seem  the  most  appropriate  for  real-time  systems.  Due  to  the 
difficulty  we  had  in  developing  an  RTL  model  of  the  elevator  system,  we  feel  that  ITL  is  more  usable 
than  RTL.  However,  our  state  predicate  approach  that  uses  only  the  state  predicate  portions  of 
RTL  appears  to  be  much  more  useful  than  ITL. 

We  have  found  that  the  most  useful  approach  for  analyzing  systems  with  respect  to  availability  is: 

a.  Develop  a  CSP  specification  of  the  system  ignoring  the  possibility  of  faults. 

b.  Determine  the  set  of  faults  to  be  tolerated  and  the  effects  of  each  fault. 

c.  Extend  the  CSP  specification  of  the  system  to  address  the  possibility  of  faults. 

d.  Demonstrate  that  the  system  satisfies  our  fault  tolerance  policy.  Since  this  demonstrates  that 
no  new  behaviors  are  introduced  by  faults,  the  possibility  of  faults  can  be  ignored  in  any 
subsequent  analysis. 

e.  Demonstrate  that  the  CSP  specification  that  ignores  the  possibility  of  faults  satisfies  any  of 
our  availability  policies  that  are  desired. 

This  provides  an  argument  that  the  system  satisfies  the  availability  policies  even  in  the  presence  of 
the  classes  of  faults  addressed  by  the  fault  tolerance  mechanism. 

Since  it  is  not  reasonable  to  incorporate  real-time  into  CSP,  this  approach  must  be  modified  for 
systems  with  real-time  policies.  The  two  main  changes  are: 

a.  A  formalism  such  as  timed  state  predicates  should  be  used  rather  than  CSP. 
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b.  The  effect  of  fault  tolerance  mechanisms  on  the  behavior  of  the  system  must  be  considered  in 
the  specifications  of  the  system. 

Due  to  the  application  specific  nature  of  real-time  policies,  we  worked  an  example  of  the  analysis 
of  a  real-time  system  with  regard  to  a  real-time  policy  rather  than  attempting  to  define  a  general 
policy.  Although  the  system  we  analyzed  is  relatively  simple,  the  same  approach  can  be  used  for 
more  complex  systems. 

We  found  that  the  most  reasonable  way  to  address  trade-offs  between  secrecy  and  availability  is  to 
weaken  the  respective  policies  to  obtain  a  policy  that  clearly: 

a.  Identifies  the  conflicts  between  secrecy  and  integrity. 

b.  Identifies  the  degree  of  secrecy  and  integrity  that  holds  in  each  case  of  conflict. 

c.  Identifies  the  absolute  policies  that  hold  when  there  are  no  conflicts. 

For  example,  conditional  noninterference  can  be  used  to  require  that  there  be  no  violation  of  the 
secrecy  policy  except  for  certain  well-defined  exceptions.  A  complete  policy  can  be  obtained  by 
extending  the  policy  to  define  the  permissible  actions  the  system  can  take  for  each  of  the  exceptions. 
Other  ways  of  weakening  policies  to  remove  conflicts  include  stochastic  policies  and  the  concept  of 
effectively  ignoring. 

In  order  to  demonstrate  the  usefulness  of  the  policies  and  approaches  described  in  this  report,  it  is 
necessary  to  apply  them  to  more  realistic  systems.  By  providing  a  worked  example  of  the  analysis 
of  a  moderately  complex  system,  the  policies  and  approaches  can  be  validated.  In  addition,  due 
to  the  generality  of  the  policies  and  approaches,  it  should  be  straightforward  for  system  developers 
and  analysts  to  use  the  worked  example  as  a  guide  to  follow  in  the  analysis  of  their  systems.  Since 
the  system  analyzed  should  be  a  secure,  distributed  system,  Distributed  Trusted  Mach  and  Theta- 
DOS  are  the  most  reasonable  candidates  for  the  worked  example.  Although  both  systems  are  too 
complex  to  analyze  merely  as  a  proof  of  concept,  a  representative  portion  of  either  system  could 
be  analyzed  as  the  worked  example. 
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